Respuesta

La biblioteca estándar de Rust ofrece los principales primitivos de sincronización para trabajar de manera segura con la multihilo:

• Mutex — proporciona exclusión mutua para el acceso a datos desde varios hilos;
• RwLock — permite varios lectores (read) al mismo tiempo, pero solo un escritor (write);
• Condvar — primitivo de variable condicional para organizar la activación de hilos por evento;
• Tipos atómicos (AtomicBool, AtomicUsize, etc.) — operaciones de lectura/escritura sin bloqueos, a nivel de hardware;
• Arc (Conteo de Referencias Atómico) — conteo de referencias con seguridad de hilo, para la propiedad compartida de objetos.

Elección:

• Si solo se requiere lectura simultáneamente — utiliza RwLock (más eficiente que Mutex).
• Para acceso sincronizado sencillo de un hilo — Mutex.
• Para sincronización por señal (por ejemplo, "esperar un nuevo elemento") — Condvar.
• Para contadores/banderas atómicas — Atomic.
• Para propiedad compartida (multihilo) — Arc.

Ejemplo:

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

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

    for _ in 0..10 {
        let counter = Arc::clone(&counter);
        let handle = thread::spawn(move || {
            let mut num = counter.lock().unwrap();
            *num += 1;
        });
        handles.push(handle);
    }

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

    println!("Resultado: {}", *counter.lock().unwrap());
}

Pregunta capciosa

Pregunta: ¿Garantiza Rust que el uso de Mutex<T> elimina completamente los deadlocks mediante la comprobación en tiempo de compilación?

Respuesta: No. Rust asegura acceso seguro a los datos mediante propiedad y el comprobador de préstamos, pero no protege contra deadlocks a nivel del lenguaje. Los bloqueos muertos surgen lógicamente al violar el orden de adquisición de múltiples Mutex o su adquisición recursiva. Ejemplo:

use std::sync::Mutex;
let lock1 = Mutex::new(0);
let lock2 = Mutex::new(0);
// Hilo 1: lock1 -> lock2, Hilo 2: lock2 -> lock1 ⇒ deadlock

---

Historia

El proyecto de procesamiento de datos experimentaba "congelamientos" aleatorios. Resultó que los desarrolladores utilizaban Mutex anidados (Mutex dentro de Mutex) sin un estricto orden de adquisición, lo que llevaba a bloqueos mutuos (deadlock), que solo se podían resolver con la finalización forzada del proceso.

Historia

En un gran servicio, migraron masivamente de Mutex<Option<T>> a RwLock<T>, sin tener en cuenta que el bloqueo escribible podía ser más prolongado que el bloqueo de lectura. En picos de carga, esto resultó en retrasos de procesamiento de hasta decenas de segundos debido a las colas en write.

Historia

Los programadores intentaron economizar en hilos, "empujando" Arc<Mutex<_>> en cientos de hilos. Debido a los detalles del funcionamiento del programador y la reutilización de mutex, aparecieron sorprendentes esperas mutuas — ¡la productividad se redujo 5 veces!