Compartir datos mutables entre hilos: por qué el compilador lo bloquea

Llegamos al corazón del asunto. Lanzar un hilo con datos propios es fácil; el verdadero problema de la concurrencia es compartir estado mutable: que dos hilos vean el mismo dato y al menos uno lo modifique. Ahí es donde otros lenguajes dejan la puerta abierta a la carrera de datos —dos hilos tocando la misma memoria sin coordinación, uno escribiendo—, el error más traicionero de la programación de sistemas, porque no falla siempre y no deja rastro. Rust cierra esa puerta en tiempo de compilación, y lo hace sin inventar reglas nuevas: reutiliza la regla que ya conoces, alias o mutación pero nunca ambas, elevada a la frontera entre hilos. Esta lección muestra por qué cada intento ingenuo de compartir y mutar entre hilos no compila, y deja servido el mecanismo —Send, Sync, Arc— que el nivel 30 formaliza.

Compartir y mutar: dos deseos que chocan

La regla nuclear del borrow checker, la que gobierna todo el lenguaje, es alias XOR mutación: en cualquier instante un dato puede tener muchos lectores (&T) o un único escritor (&mut T), nunca las dos cosas. Compartir estado mutable entre hilos pide justo lo prohibido: varios hilos que aliasan el dato y alguno que lo muta. La colisión no es un accidente de implementación; es lógica, y por eso el compilador la detiene antes de ejecutar nada.

Una carrera de datos es, con precisión, ese cruce: dos o más hilos acceden a la misma dirección, al menos uno escribe, y no hay sincronización que ordene los accesos. Es exactamente alias + mutación sin coordinación. La regla que Rust inventó para impedir un uso-tras-liberación dentro de un hilo resulta ser, palabra por palabra, la que impide una carrera de datos entre hilos.

move da posesión exclusiva, no compartida

El primer instinto es usar move. Pero move no comparte: da posesión, y la posesión es de uno solo. Con tipos Copy el efecto sorprende —copia, y cada hilo muta su propia copia sin tocar al original—:

use std::thread;

fn main() {
    let mut contador = 0;                       // i32 es Copy

    let h1 = thread::spawn(move || contador + 1);   // copia contador dentro
    let h2 = thread::spawn(move || contador + 10);  // otra copia, independiente

    println!("suman: {}", h1.join().unwrap() + h2.join().unwrap());
    println!("el original sigue en {contador}");    // 0: nadie lo compartio
}

Creíste compartir y en realidad duplicaste: los hilos operan sobre copias aisladas y el contador de main no cambia. Con un tipo no-Copy el compilador es aún más tajante, porque mover al primer hilo agota el valor:

use std::thread;

fn main() {
    let datos = vec![1, 2, 3];

    let h1 = thread::spawn(move || datos.len());
    // let h2 = thread::spawn(move || datos.len());  // ERROR: use of moved value
    println!("{}", h1.join().unwrap());
}

datos se movió al primer hilo; el segundo ya no tiene nada que mover. La moraleja es estructural: move expresa transferencia, no reparto. O bien copia (y entonces no hay estado común), o bien entrega a un único dueño (y entonces el otro hilo queda fuera). En ninguno de los dos casos existe el peligro, y por eso ninguno necesita ser bloqueado: la ausencia de compartición es la ausencia de carrera.

Rc no cruza: el contador no es atómico

Para tener varios dueños de un mismo dato ya conoces Rc. El reflejo natural es clonar un Rc y mover una copia a cada hilo. El compilador lo prohíbe en seco:

use std::rc::Rc;
use std::thread;

fn main() {
    let compartido = Rc::new(vec![1, 2, 3]);
    let clon = Rc::clone(&compartido);

    let h = thread::spawn(move || {
        println!("{clon:?}");   // ERROR: `Rc<Vec<i32>>` cannot be sent between threads
    });
    h.join().unwrap();
}

El motivo es preciso. Un Rc mantiene su recuento de referencias con enteros no atómicos: clonar hace contador += 1, soltar hace contador -= 1, operaciones que no son indivisibles. Si dos hilos clonaran o soltaran el mismo Rc a la vez, esos incrementos podrían pisarse —una carrera sobre el propio contador— y acabar liberando la memoria mientras alguien aún la usa, o no liberándola nunca. Rust codifica esa fragilidad marcando Rc como !Send: no es transportable a otro hilo. El compilador, al ver que spawn exige F: Send y que la clausura captura un Rc, deduce que la clausura no es Send y rechaza el programa. La carrera nunca llega a existir porque el tipo que la haría posible no cruza la frontera.

flowchart TD
D[Dato mutable compartido entre dos hilos] --> A[Exige alias los dos hilos lo ven]
D --> M[Exige mutacion al menos uno escribe]
A --> R[Regla de Rust alias o mutacion nunca ambas]
M --> R
R --> B[El compilador lo bloquea en compilacion sin sincronizacion]
B --> N[Arc mas Mutex reintroduce ambas con seguridad en el nivel 30]
style D fill:#f38ba8,color:#11111b
style R fill:#cba6f7,color:#11111b
style B fill:#89b4fa,color:#11111b
style N fill:#a6e3a1,color:#11111b