Storia della domanda
Durante la genesi di Rust, i progettisti si trovarono di fronte a un'impasse critica: strutture dati essenziali come grafi ciclici e contenitori controllati dal prestito a runtime richiedevano mutazione tramite riferimenti condivisi, ma questo contravveniva direttamente all'assioma fondamentale del linguaggio di accesso mutabile esclusivo. Per risolvere questo problema senza compromettere il principio di astrazione a costo zero, è stato introdotto UnsafeCell come l'unico primitivo che opta fuori dalla garanzia di immutabilità associata ai riferimenti condivisi &T, fungendo da base per tutte le astrazioni sicure di mutabilità interna.
Il problema
Il compilatore Rust sfrutta l'immutabilità di &T per eseguire ottimizzazioni aggressive, come il caching dei valori e il riordino delle istruzioni, assumendo che la memoria sottostante non possa cambiare per la durata del riferimento. UnsafeCell segnala al compilatore che il suo contenuto può mutare anche quando accesso tramite un riferimento condiviso, disabilitando effettivamente queste ottimizzazioni per i dati racchiusi. Tuttavia, questa disattivazione non si estende ai riferimenti derivati dal puntatore raw ottenuto tramite UnsafeCell::get(); nel momento in cui questo puntatore viene convertito in &mut T, le normali regole di aliasing si riafferma con rigidità assoluta.
La soluzione
La soluzione richiede che il programmatore mantenga l'invariante che qualsiasi riferimento mutabile &mut T prodotto dal puntatore raw di UnsafeCell deve essere l'unico percorso di accesso attivo a quella memoria per tutta la sua durata. Questa esclusività vieta letture o scritture contemporanee tramite qualsiasi altro puntatore, riferimento o chiamate successive a get() durante l'esistenza del riferimento mutabile. UnsafeCell non disabilita il borrow checker; trasferisce semplicemente la responsabilità di garantire l'esclusività temporale e prevenire le condizioni di race dal compilatore allo sviluppatore.
Descrizione del problema
Stavamo architettando un aggregatore di metriche ad alta capacità per un sistema di trading a bassa latenza in cui più thread aggiornavano i contatori associati a strumenti finanziari specifici. La mappa condivisa era immutabile dopo l'inizializzazione, ma i valori delle metriche richiedevano frequenti incrementi. L'uso di Mutex<u64> ha introdotto una contesa inaccettabile, mentre AtomicU64 si è dimostrato insufficiente per tipi di metriche composite complesse. Avevamo bisogno di aggiornamenti senza blocchi e senza allocazione di memoria per le strutture dietro puntatori Arc senza controlli di prestito a runtime.
Diverse soluzioni considerate
Soluzione 1: Mutex a shard
Abbiamo valutato di racchiudere ogni metrica in un Mutex e distribuirle su 256 shard per ridurre la contesa. Questo approccio offriva sicurezza diretta e codice semplice e manutenibile. Tuttavia, il profiling ha rivelato che anche le operazioni Mutex non contese consumavano centinaia di nanosecondi a causa delle syscall futex e dei protocolli di coerenza della cache, violando il nostro rigoroso budget di latenza sub-microsecondi.
Soluzione 2: AtomicPtr con valori incapsulati
Un altro approccio prevedeva di memorizzare i valori come AtomicPtr<Metric> e utilizzare cicli di compare-and-swap per gli aggiornamenti. Questo eliminava il blocco ma necessitava di allocare nuove istanze di Box per ogni incremento, portando a una forte pressione sulla memoria e contesa del gestore di memoria. Inoltre, ha complicato il recupero di memoria, richiedendo puntatori hazard o garbage collection basata su epoche che aumentavano significativamente la complessità del codice e l'area di audit.
Soluzione 3: UnsafeCell con allineamento della cache
Abbiamo scelto di memorizzare le metriche in UnsafeCell<Metric> all'interno di strutture allineate alla cache, garantendo che i thread che scrivono su diversi shard non condividessero mai righe di cache. Ogni thread otteneva un puntatore raw tramite UnsafeCell::get(), lo convertiva in &mut Metric durante l'aggiornamento—garantito sicuro dalla nostra logica di sharding che assicurava che nessun altro thread potesse accedere a quello specifico slot—e effettuava la mutazione. Ciò richiedeva blocchi unsafe e una prova formale che la nostra hashizzazione coerente assicurasse nessuna collisione durante l'accesso concorrente.
Quale soluzione è stata scelta e perché
Abbiamo selezionato la Soluzione 3 perché forniva un'astrazione a costo zero sulla memoria raw soddisfacendo i rigorosi requisiti di latenza. La garanzia di sharding agiva come prova manuale di accesso esclusivo, permettendoci di sfruttare UnsafeCell senza sovraccarichi di sincronizzazione a runtime. Abbiamo validato la sicurezza utilizzando MIRI e il modello di verifica della concorrenza loom per verificare esaustivamente che non si fossero verificati violazioni di aliasing sotto tutti i possibili interleaving di thread.
Risultato
L'implementazione ha raggiunto latenze di aggiornamento inferiori ai 100 nanosecondi con zero allocazioni nel percorso caldo. Tuttavia, è emersa una sottile regressione durante una successiva rifattorizzazione in cui un compito di manutenzione ha accidentalmente iterato su tutti gli shard senza acquisire il lock implicito dello shard, creando due riferimenti mutabili alla stessa metrica. MIRI ha immediatamente segnalato questo come comportamento indefinito durante CI, rafforzando che UnsafeCell richiede disciplina rigorosa anche quando il design architettonico garantisce teoricamente la sicurezza.
Perché è un comportamento indefinito detenere due riferimenti mutabili derivati da un UnsafeCell simultaneamente, anche se UnsafeCell opta esplicitamente fuori dalle norme di prestito standard?
UnsafeCell opta fuori dalla garanzia di immutabilità per i riferimenti condivisi a livello di tipo, ma non annulla l'invariante fondamentale del tipo &mut T stesso. Quando chiami get(), ricevi un puntatore raw *mut T che non porta vincoli di vita o aliasing. Tuttavia, nel momento in cui dereferenzi questo puntatore in un &mut T, affermi al compilatore che questo riferimento è esclusivo. Creare due di tali riferimenti a memoria sovrapposta, anche dallo stesso UnsafeCell, viola la regola dell'aliasing XOR mutazione che sottende il modello di memoria di Rust, portando a un comportamento indefinito immediato indipendentemente da come i riferimenti siano stati costruiti.
Come rileva MIRI le violazioni delle invarianti di UnsafeCell e perché il codice potrebbe superare i test di produzione ma fallire sotto MIRI?
MIRI implementa il modello di aliasing Stacked Borrows (o opzionalmente Tree Borrows), che traccia i permessi di accesso alla memoria attraverso "tag" astratti. Quando crei un riferimento da un UnsafeCell, MIRI assegna un tag unico. Qualsiasi tentativo di utilizzare un tag diverso per accedere alla stessa memoria mentre il primo riferimento è attivo costituisce una violazione. Il codice supera spesso i test standard perché i modelli di memoria hardware sono indulgenti e le condizioni di race benigne potrebbero non manifestarsi come crash in pratica. MIRI, tuttavia, applica rigorosamente il modello teorico, catturando trasgressioni come l'invalidazione di un riferimento mutabile creando un riferimento condiviso dallo stesso UnsafeCell senza una sincronizzazione adeguata, anche se l'assemblaggio funziona per l'attuale architettura CPU.
Spiega perché Cell<T> non richiede blocchi unsafe per la mutazione mentre UnsafeCell<T> sì, e identifica la garanzia di sicurezza specifica che consente questa distinzione.
Cell<T> raggiunge la mutabilità interna senza unsafe non esponendo mai riferimenti ai suoi dati interni; consente solo la copia dei valori in (set) o fuori (get) per i tipi che implementano Copy, o il loro spostamento (replace) per i tipi non-Copy. Poiché Cell non restituisce mai un &T o &mut T al valore contenuto, è impossibile violare le regole di aliasing—non ci sono riferimenti da aliasare. UnsafeCell, al contrario, fornisce get() che restituisce un puntatore raw *mut T, consentendo la creazione di riferimenti. Questa flessibilità è necessaria per mutazioni complesse in loco, ma sposta completamente l'onere di garantire l'esclusività e prevenire le condizioni di race sul programmatore, richiedendo blocchi unsafe.