Когда использовать Mutex, а когда RwLock в Rust для многопоточности?

Ключевое различие: семантика доступа

Mutex и RwLock решают одну задачу — защиту данных от гонок, но с разной стратегией. Mutex даёт эксклюзивный доступ: только один поток может владеть блокировкой, независимо от того, читает он или пишет. RwLock различает читателей и писателей: множество читателей могут работать одновременно, но писатель блокирует всех.

Когда выбирать Mutex

Mutex — ваш выбор, если:

• Операции записи часты (>20-30% всех операций). При частых записях RwLock будет работать хуже, так как писатель блокирует даже чтение, а переключение между режимами (read→write) добавляет накладные расходы.
• Критическая секция короткая (микросекунды). Если вы просто увеличиваете счётчик или обновляете одно поле, оверхед RwLock (дополнительная логика для подсчёта читателей) может превысить выгоду от параллельного чтения.
• Простота и предсказуемость. Mutex проще в использовании и отладке. Он не страдает от "голодания" писателей (в стандартной реализации std::sync::Mutex используется справедливая очередь).

Пример, где Mutex оправдан — защита счётчика обращений:

use std::sync::{Arc, Mutex};
use std::thread;

let counter = Arc::new(Mutex::new(0u64));
let mut handles = vec![];

for _ in 0..100 {
    let c = Arc::clone(&counter);
    handles.push(thread::spawn(move || {
        for _ in 0..1000 {
            let mut num = c.lock().unwrap();
            *num += 1; // короткая запись
        }
    }));
}
// Результат: 100_000

Когда выбирать RwLock

RwLock выигрывает при:

• Доминирующем чтении (>80-90% операций). Пример: кэш конфигурации, который редко обновляется, но часто читается десятками потоков.
• Длительных операциях чтения. Если чтение занимает миллисекунды (например, парсинг большого JSON), параллельный доступ даёт существенный прирост производительности.
• Необходимости атомарного обновления. RwLock позволяет выполнить "обновление через чтение" (upgradeable read lock) — вы читаете, а потом, если нужно, повышаете блокировку до записи без отпускания (только в некоторых реализациях, например parking_lot::RwLock).

Ваш пример с кэшем — идеальный кандидат для RwLock:

use std::sync::{Arc, RwLock};
use std::thread;
use std::collections::HashMap;

fn main() {
    let cache = Arc::new(RwLock::new(HashMap::new()));
    let mut handles = vec![];

    // Потоки-читатели (90%)
    for i in 0..9 {
        let cache = Arc::clone(&cache);
        handles.push(thread::spawn(move || {
            let data = cache.read().unwrap();
            println!("Reader {} sees: {:?}", i, data.get(&0));
            // Множество читателей могут работать одновременно
        }));
    }

    // Поток-писатель (10%)
    let cache_w = Arc::clone(&cache);
    handles.push(thread::spawn(move || {
        let mut data = cache_w.write().unwrap();
        data.insert(0, "initial_value".to_string());
        println!("Writer updated cache");
    }));

    for h in handles {
        h.join().unwrap();
    }
}

Важные предостережения

• Голодание писателей — реальная проблема в std::sync::RwLock (и в parking_lot по умолчанию). Если потоки-читатели непрерывно удерживают блокировку, писатель может ждать очень долго. Решение: используйте RwLock::write() с таймаутом или переключайтесь на Mutex при обнаружении "голодания".
• Производительность. Измеряйте! В реальных бенчмарках RwLock может быть медленнее Mutex при 4-8 потоках и 50% записи. Всегда тестируйте на вашем сценарии.
• Библиотеки. Рассмотрите parking_lot — его RwLock быстрее стандартного и имеет опцию Fair для предотвращения голодания.

Итоговое правило

Используйте Mutex по умолчанию — это безопасный выбор. Переходите на RwLock только если профилирование показало, что Mutex стал узким местом, и вы уверены, что чтение доминирует (минимум 80% операций). Для кэшей, конфигураций и редко обновляемых данных RwLock — отличный инструмент.

use std::sync::mpsc;
use std::thread;

let (tx, rx) = mpsc::channel();
let mut local_cache = HashMap::new();

// Поток-писатель отправляет обновления
thread::spawn(move || {
    tx.send(("key".to_string(), "value".to_string())).unwrap();
});

// Читатель получает обновления и работает с локальной копией
while let Ok((k, v)) = rx.recv() {
    local_cache.insert(k, v);
    // Ч