Mutex: exclusión mutua con la cerradura pegada al dato

Compartir un dato mutable entre hilos es, sin ceremonia, la definición misma de una carrera de datos: dos hilos tocando la misma memoria, al menos uno escribiendo, sin orden que los coordine. El resultado es corrupción no determinista, el peor bug que existe. La respuesta clásica es la exclusión mutua: un turno que solo un hilo posee a la vez. Rust materializa ese turno en Mutex<T>, pero con un giro que lo distingue de casi cualquier otro lenguaje: la cerradura no es un objeto aparte del dato que protege, sino que envuelve el dato. No existe forma de mirar el interior sin antes tomar el turno. La disciplina que en C vivía en tu cabeza y en los comentarios, aquí vive en el sistema de tipos.

El dato vive dentro de la cerradura

En pthreads o en Java el mutex y el dato son objetos separados; nada del lenguaje impide leer el dato sin bloquear primero. En Rust eso es imposible por construcción:

use std::sync::Mutex;

let saldo = Mutex::new(100u64);      // el dato queda envuelto por el Mutex

{
    let mut guard = saldo.lock().unwrap();  // tomamos el turno
    *guard += 50;                           // acceso exclusivo via DerefMut
    println!("saldo interno: {}", *guard);
}                                            // fin de scope: Drop libera la cerradura

let total = *saldo.lock().unwrap();          // otro turno, ya liberado el anterior

Mutex::new consume el valor y lo esconde: a partir de ahí saldo es un Mutex<u64>, no un u64, y no hay campo público que leer. El único camino al u64 es lock(). Fíjate en un detalle central: lock() devuelve &Mutex<T> desde una referencia compartida y aun así te entrega acceso mutable al interior. Eso es mutabilidad interior sincronizada: Mutex es, para el mundo multihilo, lo que RefCell es para el monohilo, pero comprobando la exclusividad con un turno real en vez de con un contador de préstamos.

El guard es RAII: adquirir es construir, liberar es destruir

lock() no devuelve tu T; devuelve un MutexGuard<'_, T>, un valor que prueba en tiempo de ejecución que sostienes el turno. El guard implementa Deref y DerefMut, por eso *guard te da el &T o &mut T; e implementa Drop, por eso liberar la cerradura no es una llamada que puedas olvidar, sino la consecuencia automática de que el guard salga de scope.

use std::sync::Mutex;

let m = Mutex::new(String::new());

let mut g = m.lock().unwrap();
g.push_str("hola");
drop(g);                 // liberacion explicita y TEMPRANA
// aqui la cerradura ya esta libre; g no existe

let g2 = m.lock().unwrap();
println!("{}", *g2);     // g2 se liberara al final del bloque

La liberación temprana con drop(g) importa más de lo que parece: mientras sostienes el guard nadie más puede entrar, así que la duración del guard es la duración de la sección crítica. Mantén esa sección mínima. Si tras mutar el dato vas a hacer trabajo largo —un cálculo pesado, una llamada de red—, copia lo que necesites, suelta el guard y trabaja fuera del turno. Un guard sostenido de más es contención gratuita, y sostenerlo mientras llamas a código ajeno es una receta de interbloqueo que verás en la última lección.

Envenenamiento: un pánico con el lock tomado deja cicatriz

¿Qué ocurre si un hilo toma el guard, empieza a mutar el dato y entra en panic! a mitad, dejando la invariante rota? El desenrollado libera el guard —es Drop, se ejecuta—, pero el dato puede haber quedado en un estado inconsistente. Rust no lo oculta: marca el Mutex como envenenado. A partir de ahí, todo lock() devuelve Err(PoisonError).

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

let datos = Arc::new(Mutex::new(vec![1, 2, 3]));

let d = Arc::clone(&datos);
let _ = thread::spawn(move || {
    let mut v = d.lock().unwrap();
    v.push(4);
    panic!("fallo con el lock tomado");   // envenena el Mutex al desenrollar
}).join();

match datos.lock() {
    Ok(v) => println!("intacto: {v:?}"),
    Err(envenenado) => {
        let v = envenenado.into_inner();  // reclamamos el dato, asumiendo el riesgo
        println!("recuperado tras panico: {v:?}");
    }
}

El envenenamiento no es un castigo: es una notificación de tipo. El Err te obliga a reconocer explícitamente que el dato pudo quedar a medio construir antes de seguir usándolo. Si decides que el estado es aceptable, PoisonError::into_inner() te devuelve el guard y sigues; el .unwrap() habitual toma la decisión opuesta —propagar el pánico— que casi siempre es la correcta, porque un dato compartido corrupto es exactamente la clase de fallo que no quieres arrastrar en silencio.

flowchart TD
A[Hilo llama a lock] --> B[Si el Mutex esta ocupado el hilo espera su turno]
B --> C[Al liberarse recibe un MutexGuard]
C --> D[Lee o muta el dato via Deref y DerefMut]
D --> E[Al salir de scope Drop libera la cerradura]
E --> F[El siguiente hilo ya puede adquirirla]
D --> G[Si entra en panico con el lock tomado el Mutex queda envenenado]
G --> H[El proximo lock devuelve Err para no leer a ciegas]
style A fill:#89b4fa,color:#11111b
style C fill:#a6e3a1,color:#11111b
style E fill:#cba6f7,color:#11111b
style G fill:#f38ba8,color:#11111b

El coste, los atómicos y las alternativas

Un Mutex no es la única herramienta, ni siempre la más barata. Para un dato que es un simple entero o una bandera, un tipo atómico evita el candado por completo: la operación viaja directa al hardware, sin turno ni bloqueo.

use std::sync::atomic::{AtomicU64, Ordering};

static PETICIONES: AtomicU64 = AtomicU64::new(0);

PETICIONES.fetch_add(1, Ordering::Relaxed);   // incremento atomico, sin lock
let total = PETICIONES.load(Ordering::Relaxed);

Los atómicos (AtomicU64, AtomicBool, AtomicUsize) sirven cuando el estado compartido es un número o un puntero; para cualquier cosa más rica —una struct, un Vec, un HashMap— sigue haciendo falta el Mutex. Y si el envenenamiento te estorba, o mides que el candado de std es un cuello de botella, parking_lot::Mutex ofrece un candado de terceros más rápido, sin envenenamiento, y cuyo lock() devuelve el guard directamente, sin Result. La regla: el dato más simple que resuelva tu problema —atómico si es un número, Mutex si es una estructura, candado externo solo si la medición lo justifica—.