Fearless concurrency: qué garantiza Rust y por qué es revolucionario

“Concurrencia sin miedo” no es un eslogan de marketing: es una afirmación técnica precisa, y merece enunciarse con exactitud para no prometer de más ni de menos. Rust garantiza que el código seguro está libre de carreras de datos, y lo garantiza en tiempo de compilación: no hay detector que ejecutar, no hay suerte que tener en las pruebas, no hay heisenbug que solo aparece en producción un martes. Si compila, no hay carrera de datos. Esa frase, que suena modesta, invierte la historia entera de la programación concurrente, donde este error —el más temido de los sistemas— se combatía con disciplina frágil, detectores probabilistas o renuncias al rendimiento. Esta lección cierra el nivel diciendo con rigor qué garantiza Rust, qué no garantiza, cómo lo consigue con las reglas que ya dominas, y por qué eso constituye un cambio de época.

Qué garantiza exactamente: cero carreras de datos

Una carrera de datos tiene una definición técnica estricta: ocurre cuando dos o más hilos acceden a la misma posición de memoria a la vez, al menos uno escribe, y no hay sincronización que ordene esos accesos. Es comportamiento indefinido, igual que en C o C++: el compilador y el hardware pueden reordenar y romper cualquier suposición, produciendo valores imposibles, corrupción o fallos que desafían toda depuración.

La garantía de Rust es tajante y acotada: el código seguro no puede contener carreras de datos, y esto se verifica al compilar. No es una recomendación ni una tendencia estadística; es una propiedad del sistema de tipos. Los tres pilares que ya conoces bastan para sostenerla:

• Posesión: cada valor tiene un dueño; moverlo a un hilo transfiere ese dominio. Un dato poseído por un hilo no está aliasado por otro.
• Préstamo (alias XOR mutación): muchos &T o un único &mut T, nunca a la vez. Sin alias-más-mutación no hay carrera posible, por definición.
• Send y Sync: los marcadores que llevan esas reglas a través de la frontera del hilo, decidiendo qué tipos pueden migrar o compartirse sin romper sus invariantes.

La consecuencia práctica es que el sistema de tipos te encauza hacia la corrección: para tener estado mutable compartido entre hilos estás obligado a usar un tipo que aporte sincronización, porque solo esos son Sync mientras permiten mutar. El patrón canónico combina Arc (posesión compartida con contador atómico) y Mutex (mutación serializada):

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

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

    for _ in 0..4 {
        let c = Arc::clone(&contador);          // otro puntero al mismo Mutex
        handles.push(thread::spawn(move || {
            *c.lock().unwrap() += 1;            // el cerrojo serializa el acceso
        }));
    }
    for h in handles { h.join().unwrap(); }

    println!("total: {}", *contador.lock().unwrap());   // siempre 4, sin carrera
}

Sustituye Arc<Mutex<u64>> por un simple u64 compartido por referencia y el programa deja de compilar: un &u64 no permite mutar, y ningún tipo de mutación compartida sin sincronizar es Sync. El compilador no te dicta el cerrojo, pero rechaza toda alternativa que no lo tenga, de modo que el único camino que compila es también el único correcto. Los detalles de Arc, Mutex y los tipos atómicos llegan en el nivel 30; aquí basta con reconocer la forma de la garantía.

Qué NO garantiza: carreras lógicas y deadlocks

La integridad de la afirmación depende de decir también lo que queda fuera. Rust previene la carrera de datos —un fenómeno a nivel de memoria—, no toda condición de carrera a nivel de lógica. Son cosas distintas:

• Una carrera lógica es cualquier resultado que dependa del entrelazado de los hilos: dos transferencias bancarias correctamente sincronizadas (cada acceso protegido por su Mutex) pero aplicadas en un orden que deja un saldo inesperado. No hay carrera de datos —ningún acceso sin sincronizar— y sin embargo el resultado es un bug. Rust no lo impide, porque es un error de tu lógica, no de la memoria.
• Un deadlock es igual de posible: dos hilos que toman dos Mutex en orden opuesto pueden quedar bloqueados para siempre, cada uno esperando el cerrojo que el otro sostiene. El programa compila y es memory-safe; simplemente se cuelga.

Esta frontera no es una debilidad; es honestidad. Rust erradica la clase de fallos concurrentes que corrompen memoria y desafían la depuración, y deja en tus manos la corrección algorítmica, que ningún sistema de tipos razonable puede garantizar. “Sin miedo” no significa “sin pensar”.

Por qué es revolucionario

Para medir la magnitud del cambio hay que recordar cómo se lograba la seguridad concurrente antes. Cada estrategia histórica pagaba un precio:

Rust ofrece una quinta vía que no aparecía en el menú: garantía estática, con memoria compartida real, a coste cero en ejecución, y sin sacrificar el paralelismo. Puedes tener varios hilos mutando distintas partes de una estructura, o compartiendo estado a través de un Mutex, con la certeza —comprobada antes de ejecutar— de que ninguna combinación de entrelazados produce una carrera de datos. El término lo acuñó el equipo de Rust en 2015, y su sentido es psicológico además de técnico: puedes refactorizar y paralelizar sin miedo, porque el compilador rechaza el código incorrecto en lugar de castigarte con un fallo intermitente meses después.

flowchart TD
O[Posesion cada valor un solo dueno] --> RULE[Alias o mutacion nunca ambas]
B[Prestamo compartido o exclusivo] --> RULE
SS[Send y Sync gobiernan el cruce de hilos] --> RULE
RULE --> G[Cero carreras de datos en Rust seguro verificado en compilacion]
G --> SI[Si el codigo seguro compila no hay carrera de datos]
G --> NO[No cubre carreras logicas ni deadlocks]
style RULE fill:#cba6f7,color:#11111b
style G fill:#a6e3a1,color:#11111b
style SI fill:#89b4fa,color:#11111b
style NO fill:#fab387,color:#11111b