Mutex & RwLock

Quando threads precisam compartilhar estado mutável, Mutex e RwLock serializam o acesso para que apenas um escritor ou muitos leitores toquem nos dados por vez. Emparelhe-os com Arc para compartilhamento entre múltiplas threads.

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

use std::sync::{Arc, Mutex};
 
fn main() {
    let data = Arc::new(Mutex::new(Vec::new()));
    let mut guard = data.lock().unwrap();
    guard.push(1);
}

Quando usar isso: Contadores compartilhados, caches ou estado na memória atualizado por múltiplas threads quando a passagem de mensagens é complicada.

Exemplo de Trabalho

use std::sync::{Arc, RwLock};
use std::thread;
 
#[derive(Default)]
struct Cache {
    entries: RwLock<std::collections::HashMap<String, String>>,
}
 
fn main() {
    let cache = Arc::new(Cache::default());
    let mut handles = vec![];
 
    for i in 0..8 {
        let cache = Arc::clone(&cache);
        handles.push(thread::spawn(move || {
            let key = format!("key-{i}");
            if i % 3 == 0 {
                let mut map = cache.entries.write().unwrap();
                map.insert(key, format!("value-{i}"));
            } else {
                let map = cache.entries.read().unwrap();
                let _ = map.get(&key);
            }
        }));
    }
 
    for h in handles {
        h.join().unwrap();
    }
}

O que isso demonstra:

• RwLock permite leitores concorrentes.
• write exclui todo o outro acesso.
• Arc compartilha o bloqueio entre threads.

Análise Profunda

Como Funciona

• Mutex: Acesso exclusivo. Uma guarda por vez. Simples e previsível.
• RwLock: Muitos leitores OU um escritor. Melhor quando as leituras dominam.
• Envenenamento (Poisoning): Se uma thread entrar em pânico enquanto segura um bloqueio, o mutex é "envenenado". lock() retorna Err - recupere com into_inner() ou propague a falha.
• Estacionamento (Parking): Bloqueios disputados colocam as threads para dormir em vez de fazer busy-spinning (dependente do SO).

std::sync vs parking_lot

Notas de Rust

// Mantenha as seções críticas curtas
{
    let mut guard = mutex.lock().unwrap();
    guard.push(item);
} // guard é descartado aqui - bloqueio liberado antes de I/O lento
 
// Nunca segure um bloqueio através de .await em código async

• MutexGuard dereferencia para os dados internos via DerefMut.
• Prefira parking_lot em caminhos críticos quando a profilaxia mostrar sobrecarga de bloqueio.
• Considere DashMap para hash maps concorrentes fragmentados.

Armadilhas

• Deadlocks de ordem de bloqueio - Thread A bloqueia m1 e depois m2; B faz o reverso. Correção: Sempre adquira bloqueios em uma ordem global fixa.
• Seções críticas longas - Segurar bloqueios durante I/O bloqueia todos os esperadores. Correção: Clone os dados para fora, libere o bloqueio e, em seguida, faça I/O.
• RwLock para cargas de trabalho com muitas escritas - Escritores famintos impedem leitores e uns aos outros. Correção: Use Mutex ou canais.
• Mutex para dados somente leitura - Contenção desnecessária. Correção: Use Arc<T> quando os dados são imutáveis após a construção.
• Ignorar erros de envenenamento - unwrap() em envenenamento pode ocultar falhas em cascata. Correção: Registre e reinicie o estado ou desligue o serviço.

Alternativas

FAQs

Relacionado

• Arc para Estado Compartilhado - Padrão Arc<Mutex<T>>
• Send & Sync - por que bloqueios são Sync
• Deadlocks & Condições de Corrida - ordem de bloqueio
• Estado Compartilhado em Async - padrões de mutex async
• Melhores Práticas de Concorrência - minimize o escopo do bloqueio

Versões da Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.