Arc y Mutex: el patrón canónico del estado mutable compartido

Mutex<T> resuelve quién puede mutar ahora, pero deja intacta otra pregunta: quién es el dueño del dato. Un Mutex tiene un solo propietario, y para lanzar un hilo con thread::spawn tienes que mover cosas dentro de su clausura: no puedes mover el mismo Mutex a diez hilos. Necesitas que diez hilos posean a la vez el mismo Mutex. Esa es propiedad compartida, y en Rust se expresa con recuento de referencias. Pero el Rc que ya conoces no sirve: su contador no es atómico y no cruza fronteras de hilo. Su hermano sincronizado sí: Arc. La combinación Arc<Mutex<T>> es el patrón más repetido de toda la concurrencia en Rust, y su elegancia está en que no es un tipo monolítico, sino dos capacidades ortogonales encajadas.

Dos problemas distintos, dos tipos distintos

Compartir estado mutable entre hilos descompone en dos preguntas que la mayoría de lenguajes fusionan en un “objeto sincronizado” y que Rust mantiene separadas:

Ninguno de los dos basta por separado. Un Arc<T> reparte el dato pero solo da lectura: no puedes mutar a través de un &T compartido. Un Mutex<T> permite mutar pero tiene un único dueño: no puedes moverlo a varios hilos. Anidados, se completan: Arc<Mutex<T>> es “un puñado de manijas hacia un mismo dato, protegido por un turno”. Y como el orden del anidamiento cambia el significado, el tipo es una especificación precisa: Arc<Mutex<T>> comparte un dato guardado, mientras que Mutex<Arc<T>> guardaría una manija que puedes intercambiar. Casi siempre quieres el primero.

El contador compartido, palabra por palabra

Este es el “hola mundo” del estado compartido: diez hilos incrementando mil veces un mismo contador. Sin sincronización sería una carrera masiva; con Arc<Mutex<T>> el resultado es exactamente 10000, siempre.

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

fn main() {
    let contador = Arc::new(Mutex::new(0u64));
    let mut tareas = Vec::new();

    for _ in 0..10 {
        let contador = Arc::clone(&contador);   // nueva manija, mismo dato
        tareas.push(thread::spawn(move || {     // move: la clausura toma su Arc
            for _ in 0..1000 {
                let mut n = contador.lock().unwrap();
                *n += 1;
            }                                    // el guard se libera en cada vuelta
        }));
    }

    for t in tareas {
        t.join().unwrap();                       // esperamos a que todos terminen
    }

    println!("total = {}", *contador.lock().unwrap());   // 10000, garantizado
}

Léelo por capas, que es como está construido:

• Arc::clone(&contador) no copia el Mutex ni el u64: incrementa el contador atómico y devuelve otra manija hacia el mismo dato en el heap. Es barato y deliberadamente explícito —se escribe Arc::clone(&x) y no x.clone() para que el lector vea que hay un recuento en juego, no una copia profunda—.
• move obliga a la clausura del hilo a adueñarse de su clon del Arc. Sin move, la clausura intentaría tomar prestado contador, y el borrow checker lo rechazaría: el hilo puede sobrevivir a la función que lo lanzó, así que no puede depender de un préstamo.
• contador.lock().unwrap() es la parte de la lección anterior: toma el turno y devuelve un MutexGuard. *n += 1 muta a través de DerefMut. El guard se libera al final de cada vuelta del bucle, minimizando la sección crítica.
• join bloquea hasta que cada hilo acaba; sin él, main podría leer el contador antes de tiempo.

El sistema de tipos hace todo el trabajo pesado: Arc<Mutex<u64>> implementa Send y Sync (porque u64: Send), y son justo esos dos traits los que permiten que la clausura cruce a otro hilo. Si intentaras esto con Rc<RefCell<u64>>, no compilaría —y ese “no compila” es Rust cerrándote la puerta a una carrera de datos antes de que exista—.

flowchart TD
H[Arc Mutex del contador en el heap con recuento atomico]
T1[Hilo 1 con su Arc clonado] --> H
T2[Hilo 2 con su Arc clonado] --> H
T3[Hilo N con su Arc clonado] --> H
H --> L[Solo un hilo sostiene el MutexGuard a la vez]
L --> R[Suma determinista total 10000]
style H fill:#cba6f7,color:#11111b
style L fill:#89b4fa,color:#11111b
style R fill:#a6e3a1,color:#11111b

Un dato rico compartido: el mapa entre hilos

El patrón no se limita a contadores. Cualquier estructura mutable que varios hilos deban compartir sigue la misma forma; solo cambia la T:

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

fn main() {
    let cuentas: Arc<Mutex<HashMap<String, u64>>> =
        Arc::new(Mutex::new(HashMap::new()));

    let mut tareas = Vec::new();
    for _ in 0..4 {
        let cuentas = Arc::clone(&cuentas);
        tareas.push(thread::spawn(move || {
            let mut mapa = cuentas.lock().unwrap();
            *mapa.entry(String::from("ana")).or_insert(0) += 1;
        }));                                    // el guard se libera aqui
    }
    for t in tareas { t.join().unwrap(); }

    println!("{:?}", *cuentas.lock().unwrap());  // {"ana": 4}
}

La torre Arc<Mutex<HashMap<String, u64>>> se lee de fuera adentro como una frase: compartido entre hilos (Arc), con mutación arbitrada (Mutex), de un mapa de nombres a contadores (HashMap). Cada capa aporta exactamente una capacidad, y el tipo entero es la especificación completa de cómo se comparte ese estado. Añadir un RwLock en lugar del Mutex, o un atómico dentro, no cambiaría la gramática: cambiaría una palabra de la frase.