Respuesta.

La cuestión de la seguridad en entornos multihilo ha sido un desafío para los programadores durante mucho tiempo, enfrentándose constantemente a problemas de carreras, datos inconsistentes y fugas de memoria. Rust ha implementado un enfoque único con los traits de marcador Send y Sync para minimizar estos problemas incluso en la etapa de compilación.

El problema es la falta de control sobre el acceso a datos compartidos entre hilos, lo que lleva a errores difíciles de depurar. En muchos lenguajes, la responsabilidad recae completamente en el programador; en Rust, el compilador verifica automáticamente qué se puede transferir/compartir entre hilos.

La solución: el trait Send garantiza la posibilidad de transferir un objeto de manera segura de un hilo a otro. Sync permite el acceso compartido a una referencia a un objeto desde diferentes hilos. Casi todos los tipos estándar en Rust implementan automáticamente estos traits, y los tipos personalizados pueden implementarlos manualmente o prohibirlos a través de impl !Send o impl !Sync para casos específicos.

Ejemplo de código:

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

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();
}
// counter siempre será igual a 10 sin carreras!

Características clave:

Send significa la transferencia de la propiedad de un objeto entre hilos.
Sync significa el uso compartido seguro de un objeto a través de referencias.
Implementar/prohibir traits para tipos personalizados permite controlar el comportamiento en la etapa de compilación.

Preguntas trampa.

¿Puede un tipo con punteros inseguros ser Send o Sync?

No, si un tipo contiene un puntero crudo o recursos sin garantías de seguridad en hilos, no implementa estos traits, o el desarrollador debe implementarlos manualmente asumiendo toda la responsabilidad (normalmente con unsafe impl Send/Sync).

¿Son Rc<T> y RefCell<T> Send o Sync?

No, Rc<T> y RefCell<T> no son seguros para su uso en múltiples hilos (ni Send ni Sync). Para escenarios multihilo se utilizan Arc<T> y Mutex/ RwLock.

¿Qué sucede si una variable estática contiene un tipo sin implementar Sync?

Rust no permitirá que tal variable estática exista: debe ser Sync, de lo contrario, el compilador generará un error.

Errores comunes y anti-patrón

Usar Rc<T> en lugar de Arc<T> al compartir entre varios hilos.
Desarrollar estructuras con punteros inseguros internos y confiar automáticamente en el trait Send.
Romper invariantes mediante el uso de unsafe impl Send/Sync sin un control riguroso.

Ejemplo de la vida real

Caso negativo

Un joven desarrollador coloca un objeto Rc en thread::spawn; el código solo compila si Rc no se pasa entre hilos. Al intentar extraer Rc de thread::spawn, se genera un error de compilación, ya que Rc no implementa Send y no está protegido contra carreras.

Ventajas:

El compilador previene inmediatamente el error de carrera de datos.

Desventajas:

Si no se conoce la diferencia entre Rc y Arc, puede ser difícil comprender el error.

Caso positivo

Se utiliza Arc+Mutex para un contador multihilo, todos los hilos trabajan con los mismos datos a través de una interfaz segura para hilos. No hay carreras, el código es seguro y robusto.