Deadlocks: Rust previene carreras de datos, no interbloqueos

Aquí conviene ser preciso sobre lo que Rust garantiza y lo que no. El compilador demuestra, en tiempo de compilación, que tu programa no tiene carreras de datos: nunca dos hilos tocan la misma memoria sin sincronizar. Esa es una garantía de seguridad —“nada malo le pasa a la memoria”—. Pero hay otra clase de fallo concurrente que Rust no previene: el interbloqueo. Dos hilos, cada uno sosteniendo un candado y esperando el del otro, se quedan quietos para siempre. El programa no corrompe nada, no invoca comportamiento indefinido, es impecablemente seguro en el sentido de Rust; simplemente nunca progresa. La “concurrencia sin miedo” elimina la clase de bugs que corrompen memoria de forma no reproducible, y te deja al mando de la clase que solo cuelga. Entender exactamente dónde está esa línea es entender qué compraste con Rust y qué sigue siendo tu responsabilidad.

Un interbloqueo es seguro, y aun así es un bug

Este programa compila sin una sola advertencia y puede colgarse para siempre. No hay unsafe, no hay carrera de datos; hay dos hilos que toman dos candados en orden opuesto.

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

fn main() {
    let a = Arc::new(Mutex::new(0));
    let b = Arc::new(Mutex::new(0));

    let (a1, b1) = (Arc::clone(&a), Arc::clone(&b));
    let h1 = thread::spawn(move || {
        let _ga = a1.lock().unwrap();     // toma A
        let _gb = b1.lock().unwrap();     // luego espera B  -> se queda esperando
    });

    let (a2, b2) = (Arc::clone(&a), Arc::clone(&b));
    let h2 = thread::spawn(move || {
        let _gb = b2.lock().unwrap();     // toma B
        let _ga = a2.lock().unwrap();     // luego espera A  -> cierra el ciclo
    });

    h1.join().unwrap();
    h2.join().unwrap();
}

Si el primer hilo alcanza a tomar A y el segundo B antes de que ninguno tome el segundo candado, cada uno espera un recurso que el otro sostiene, y ninguno lo soltará —soltar exige avanzar, y avanzar exige el candado que falta—. El programa se queda inmóvil. Nota lo incómodo del asunto: es un bug no determinista que quizá no aparezca en mil ejecuciones y sí en la que corre en producción, porque depende del entrelazado exacto de los hilos. Rust erradicó ese no determinismo para la memoria, pero no para el tiempo.

Las cuatro condiciones, y cómo romper una

Un interbloqueo clásico necesita las cuatro condiciones de Coffman a la vez; negar cualquiera de ellas lo hace imposible. Dos las impone la naturaleza del candado, pero las otras dos están en tus manos:

La palanca más limpia es la última. Fija un orden total sobre tus candados —por dirección, por un identificador, por cualquier criterio estable— y exige que todo hilo los adquiera siempre en ese orden. En el ejemplo, basta con que ambos hilos tomen A antes que B: entonces el que consigue A acabará consiguiendo B, porque nadie que tenga B puede estar esperando A. El ciclo no se cierra porque no hay dos flechas en sentidos opuestos.

// Correccion: ambos hilos adquieren SIEMPRE a antes que b.
let h1 = thread::spawn(move || {
    let _ga = a1.lock().unwrap();
    let _gb = b1.lock().unwrap();     // mismo orden
});
let h2 = thread::spawn(move || {
    let _ga = a2.lock().unwrap();     // a primero, tambien aqui
    let _gb = b2.lock().unwrap();
});

flowchart LR
H1[Hilo 1 tiene A y espera B] --> B[Candado B]
B --> H2[Hilo 2 tiene B y espera A]
H2 --> A[Candado A]
A --> H1
style H1 fill:#f38ba8,color:#11111b
style H2 fill:#f38ba8,color:#11111b
style A fill:#fab387,color:#11111b
style B fill:#fab387,color:#11111b

Los patrones de prevención

Traduciendo las condiciones a reglas de ingeniería concretas:

• Orden global de candados. Si una operación necesita varios locks, adquiérelos siempre en el mismo orden acordado. Mata la espera circular de raíz. Es la técnica más usada donde compartir varios candados es inevitable.
• No anides candados; encoge la sección crítica. Sostén como mucho uno a la vez. Copia lo que necesites, suelta el guard con drop y trabaja fuera. Nunca llames a código ajeno o a un callback mientras sostienes un lock: podría reentrar y autobloquearte.
• try_lock con retroceso. Cuando no puedes garantizar un orden, intenta el segundo candado sin bloquear; si falla, suelta el primero, espera un poco y reintenta. Rompe “retener y esperar” a costa de posible livelock, que se mitiga con esperas aleatorias.
• Prefiere canales. La cura más radical: si el dato fluye por un mpsc en vez de quedarse tras un candado, no hay lock sobre el que interbloquearse. La transferencia de posesión de la lección anterior no solo elude las carreras de datos; elude también toda esta familia de interbloqueos, porque no queda candado que enredar.