Canales mpsc: comparte memoria comunicando

Hasta aquí, compartir estado ha significado un dato quieto con muchos hilos pidiendo turno para tocarlo: Mutex, RwLock, candados. Hay otra estrategia, opuesta en filosofía, que resume un eslogan heredado de los lenguajes de canales: no comuniques compartiendo memoria; comparte memoria comunicando. En vez de dejar un dato inmóvil y coordinar el acceso, haces que el dato viaje: un hilo lo produce, lo envía por un canal, y en ese envío cede su posesión; otro hilo lo recibe y pasa a ser su único dueño. No hay dato compartido, luego no hay candado, luego no hay carrera de datos. La biblioteca estándar ofrece esta idea en std::sync::mpsc —multiple producer, single consumer—, y su seguridad no descansa en disciplina alguna, sino en la misma ley de ownership que aprendiste hace veinte niveles.

Un emisor, un receptor, y un valor que se muda

channel() devuelve dos extremos de un mismo conducto:

use std::sync::mpsc;
use std::thread;

fn main() {
    let (tx, rx) = mpsc::channel::<String>();   // tx emisor, rx receptor

    thread::spawn(move || {
        let mensaje = String::from("resultado listo");
        tx.send(mensaje).unwrap();              // send MUEVE mensaje al canal
        // aqui 'mensaje' ya no existe: dejo de ser su dueno
    });

    let recibido = rx.recv().unwrap();          // bloquea hasta que llega uno
    println!("main recibio: {recibido}");
}

El corazón de todo está en una sola palabra: send mueve. Tras tx.send(mensaje), el emisor ya no posee mensaje; intentar usarlo después es un error de compilación, el mismo que si lo hubieras movido a otra función. La posesión ha cruzado el canal. Cuando rx.recv() lo entrega, el receptor se vuelve su único dueño. En ningún instante dos hilos poseen el valor a la vez, y por eso no hay nada que proteger.

• send(v) devuelve Result<(), SendError<T>>: falla —devolviéndote el valor— solo si el receptor ya se destruyó y nadie podrá recibirlo.
• recv() devuelve Result<T, RecvError>: bloquea hasta que llega un valor, y falla solo cuando todos los emisores se han soltado y el canal quedó vacío y cerrado. También existen try_recv (no bloquea) y recv_timeout.

Muchos productores, un consumidor

La mp de mpsc significa que el Sender se puede clonar: cada clon es otra boca del mismo canal, y así varios hilos alimentan a un único receptor.

use std::sync::mpsc;
use std::thread;

fn main() {
    let (tx, rx) = mpsc::channel::<String>();

    for id in 0..3 {
        let tx = tx.clone();                    // un emisor mas para este hilo
        thread::spawn(move || {
            tx.send(format!("hola desde el hilo {id}")).unwrap();
        });
    }
    drop(tx);                                   // soltamos el emisor original

    for msg in rx {                             // itera hasta que el canal se cierra
        println!("recibido: {msg}");
    }
}

Dos sutilezas que separan el código que funciona del que se cuelga:

• drop(tx) no es opcional. El bucle for msg in rx termina cuando el canal se cierra, y el canal solo se cierra cuando el último Sender se destruye. Los tres clones mueren al acabar sus hilos, pero el tx original sigue vivo en main; si no lo sueltas, el receptor esperará para siempre un cuarto mensaje que nunca llega. Soltarlo explícitamente cierra el conducto.
• for msg in rx consume el receptor como un iterador bloqueante: cada vuelta espera el próximo mensaje y el bucle acaba, limpiamente, cuando ya no puede llegar ninguno más. Es la forma idiomática de drenar un canal hasta el final.

El receptor es único —no se clona—, coherente con el nombre: single consumer. Si necesitas varios consumidores repartiéndose el trabajo, ese es territorio de crates como crossbeam-channel (mpmc); la biblioteca estándar se ciñe a un solo receptor.

flowchart LR
P1[Productor 1 con tx clonado] --> C[Canal cola de mensajes]
P2[Productor 2 con tx clonado] --> C
P3[Productor N con tx clonado] --> C
C --> R[Un unico receptor rx]
R --> U[send movio cada valor un solo dueno a la vez]
style C fill:#89b4fa,color:#11111b
style R fill:#a6e3a1,color:#11111b
style U fill:#cba6f7,color:#11111b

El canal como tubería: repartir y recolectar

Un uso idiomático combina las lecciones anteriores sin un solo candado: un hilo reparte trabajos, varios obreros los procesan, y los resultados vuelven por un segundo canal. La posesión de cada tarea y de cada resultado se transfiere en cada salto.

use std::sync::mpsc;
use std::thread;

fn main() {
    let (tx_res, rx_res) = mpsc::channel();

    for id in 0..4 {
        let tx_res = tx_res.clone();
        thread::spawn(move || {
            let calculo = id * id;                 // trabajo del obrero
            tx_res.send((id, calculo)).unwrap();   // cede su resultado al canal
        });
    }
    drop(tx_res);                                  // soltamos el emisor sobrante

    let mut total = 0;
    for (id, r) in rx_res {                        // recolecta hasta que se cierra
        println!("obrero {id} devolvio {r}");
        total += r;
    }
    println!("suma = {total}");
}

No hay Mutex porque no hay dato compartido: cada obrero posee su tarea, produce un resultado y lo cede al canal. El hilo principal es el único consumidor y suma lo que llega. Cuando quieras coordinar hilos, esta forma —tuberías de canales— suele ser más fácil de razonar que un enjambre de candados, precisamente porque no hay estado que dos hilos puedan pisar a la vez.