Historia de la pregunta
Durante la génesis de Rust, los diseñadores se enfrentaron a un impasse crítico: las estructuras de datos esenciales como los gráficos cíclicos y los contenedores verificados en tiempo de ejecución requerían mutaciones a través de referencias compartidas, lo que contradecía directamente el axioma fundamental del lenguaje de acceso mutable exclusivo. Para resolver esto sin comprometer el principio de abstracción de costo cero, se introdujo UnsafeCell como el único primitivo que opta por salir de la garantía de inmutabilidad asociada con las referencias compartidas &T, sirviendo como la base para todas las abstracciones de mutabilidad interior seguras.
El problema
El compilador de Rust aprovecha la inmutabilidad de &T para realizar optimizaciones agresivas, como el almacenamiento en caché de valores y el reordenamiento de instrucciones, asumiendo que la memoria subyacente no puede cambiar durante la vida útil de la referencia. UnsafeCell señala al compilador que su contenido puede mutar incluso cuando se accede a través de una referencia compartida, deshabilitando efectivamente estas optimizaciones para los datos encerrados. Sin embargo, esta opción no se extiende a las referencias derivadas del puntero bruto obtenido a través de UnsafeCell::get(); en el momento en que este puntero se convierte en &mut T, las reglas estándar de aliasing se reafirman con rigidez absoluta.
La solución
La solución requiere que el programador mantenga la invariante de que cualquier referencia mutable &mut T producida a partir del puntero bruto de UnsafeCell debe ser la única ruta de acceso activa a esa memoria durante toda su vida. Esta exclusividad prohíbe lecturas o escrituras concurrentes a través de cualquier otro puntero, referencia o llamadas posteriores a get() durante la existencia de la referencia mutable. UnsafeCell no desactiva el verificador de préstamos; simplemente transfiere la responsabilidad de garantizar la exclusividad temporal y prevenir las condiciones de carrera del compilador al desarrollador.
Descripción del problema
Estábamos arquitectando un agregador de métricas de alto rendimiento para un sistema de trading de baja latencia donde múltiples hilos actualizaban contadores asociados con instrumentos financieros específicos. El mapa compartido era inmutable después de la inicialización, pero los valores de las métricas requerían incrementos frecuentes. Emplear Mutex<u64> introducía una contención inaceptable, mientras que AtomicU64 resultó insuficiente para tipos de métricas compuestas complejas. Necesitábamos actualizaciones sin bloqueo y sin asignaciones para estructuras detrás de punteros Arc sin chequeos de préstamo en tiempo de ejecución.
Diferentes soluciones consideradas
Solución 1: Mutexes fragmentados
Evaluamos envolver cada métrica en un Mutex y distribuirlos en 256 fragmentos para reducir la contención. Este enfoque ofrecía seguridad sencilla y código simple y mantenible. Sin embargo, la evaluación mostró que incluso las operaciones de Mutex sin contención consumían cientos de nanosegundos debido a las llamadas al sistema futex y a los protocolos de coherencia de caché, violando nuestro estricto límite de latencia sub-microsegundo.
Solución 2: AtomicPtr con valores en caja
Otro enfoque consistió en almacenar valores como AtomicPtr<Metric> y utilizar bucles de comparación e intercambio para las actualizaciones. Esto eliminó el bloqueo, pero requería asignar nuevas instancias de Box para cada incremento, lo que llevaba a una fuerte presión de memoria y contención en el asignador. Además, complicó la reclamación de memoria, requiriendo punteros de peligro o recolección de basura basada en épocas que aumentaban significativamente la complejidad del código y la superficie de auditoría.
Solución 3: UnsafeCell con alineación de líneas de caché
Elegimos almacenar métricas en UnsafeCell<Metric> dentro de estructuras alineadas a la línea de caché, asegurando que los hilos que escriben en diferentes fragmentos nunca compartieran líneas de caché. Cada hilo obtenía un puntero bruto a través de UnsafeCell::get(), lo convertía en &mut Metric durante la actualización—garantizado seguro por nuestra lógica de fragmentación que aseguraba que ningún otro hilo pudiera acceder a esa ranura específica—y realizaba la mutación. Esto requería bloques unsafe y una prueba formal de que nuestro hashing consistente aseguraba que no hubiera colisiones durante el acceso concurrente.
Qué solución se eligió y por qué
Seleccionamos la Solución 3 porque proporcionaba una abstracción de costo cero sobre la memoria bruta mientras cumplía con los agresivos requisitos de latencia. La garantía de fragmentación actuó como una prueba manual de acceso exclusivo, permitiéndonos aprovechar UnsafeCell sin sobrecarga de sincronización en tiempo de ejecución. Validamos la seguridad usando MIRI y el verificador de modelos de concurrencia loom para verificar exhaustivamente que no ocurrieran violaciones de aliasing bajo todos los posibles interleavings de hilos.
Resultado
La implementación logró latencias de actualización de menos de 100 nanosegundos con cero asignaciones en el camino caliente. Sin embargo, surgió una regresión sutil durante una posterior refactorización donde una tarea de mantenimiento accidentalmente iteró sobre todos los fragmentos sin adquirir el bloqueo implícito del fragmento, creando dos referencias mutables a la misma métrica. MIRI inmediatamente señaló esto como un comportamiento indefinido durante la CI, reforzando que UnsafeCell exige disciplina rigurosa incluso cuando el diseño arquitectónico garantiza teóricamente la seguridad.
¿Por qué es un comportamiento indefinido mantener dos referencias mutables derivadas de un UnsafeCell simultáneamente, aunque UnsafeCell opta explícitamente por salir de las reglas estándar de préstamo?
UnsafeCell opta por salir de la garantía de inmutabilidad para referencias compartidas a nivel de tipo, pero no relaja la invariante fundamental del tipo &mut T en sí. Cuando llamas a get(), recibes un puntero bruto *mut T que no lleva restricciones de vida o alias. Sin embargo, en el instante en que desreferencias este puntero en un &mut T, afirmas al compilador que esta referencia es exclusiva. Crear dos tales referencias a memoria superpuesta, incluso desde el mismo UnsafeCell, viola la regla de aliasing XOR mutation que subyace al modelo de memoria de Rust, llevando a inmediato comportamiento indefinido sin importar cómo se construyeron las referencias.
¿Cómo detecta MIRI las violaciones de las invariantes de UnsafeCell y por qué podría el código pasar las pruebas de producción pero fallar bajo MIRI?
MIRI implementa el modelo de aliasing Stacked Borrows (o opcionalmente Tree Borrows), que rastrea los permisos de acceso a la memoria a través de "tags" abstractos. Cuando creas una referencia desde un UnsafeCell, MIRI asigna una etiqueta única. Cualquier intento de acceder a la misma memoria con una etiqueta diferente mientras la primera referencia está activa constituye una violación. El código a menudo pasa las pruebas estándar porque los modelos de memoria de hardware son indulgentes y las competiciones de datos benignas pueden no manifestarse como fallos en la práctica. MIRI, sin embargo, aplica rigurosamente el modelo teórico, capturando transgresiones como invalidar una referencia mutable al crear una referencia compartida desde el mismo UnsafeCell sin sincronización adecuada, incluso si el ensamblador funciona en la arquitectura de CPU actual.
Explica por qué Cell<T> no requiere bloques unsafe para mutación mientras UnsafeCell<T> sí, e identifica la garantía de seguridad específica que permite esta distinción.
Cell<T> logra mutabilidad interior sin unsafe al nunca exponer referencias a sus datos interiores; solo permite copiar valores dentro (set) o fuera (get) para tipos que implementan Copy, o moverlos (replace) para tipos no Copy. Dado que Cell nunca produce un &T o &mut T para el valor contenido, es imposible violar las reglas de aliasing—no hay referencias para alias. UnsafeCell, en cambio, proporciona get() que devuelve un puntero bruto *mut T, permitiendo la creación de referencias. Esta flexibilidad es necesaria para mutaciones complejas en su lugar, pero traslada la carga de asegurar la exclusividad y prevenir condiciones de carrera completamente al programador, exigiendo bloques unsafe.