Geschiedenis van de vraag
Tijdens de geboorte van Rust stonden de ontwerpers voor een kritische impasse: essentiële datastructuren zoals cyclische grafen en runtime-gecontroleerde containers vereisten mutatie via gedeelde referenties, terwijl dit direct in strijd was met de fundamentele axioma van de taal van exclusieve mutabele toegang. Om dit op te lossen zonder het principe van nul-kosten abstractie in gevaar te brengen, werd UnsafeCell geïntroduceerd als de enige primitief die zich onttrekt aan de onveranderlijkheidsgarantie die verband houdt met gedeelde referenties &T, en dient als de basis voor alle veilige interne mutabiliteitsabstracties.
Het probleem
De Rust compiler maakt gebruik van de onveranderlijkheid van &T om agressieve optimalisaties uit te voeren, zoals waardecaching en instructieherordening, uitgaande van de aanname dat het onderliggende geheugen gedurende de levensduur van de referentie niet kan veranderen. UnsafeCell geeft aan de compiler door dat de inhoud kan muteren, zelfs wanneer deze wordt benaderd via een gedeelde referentie, en schakelt daarmee deze optimalisaties voor de ingesloten gegevens uit. Deze opt-out strekt zich echter niet uit tot de referenties die zijn afgeleid van de ruwe pointer verkregen via UnsafeCell::get(); op het moment dat deze pointer wordt omgezet naar &mut T, herbevestigen de standaard aliasregels zich met absolute rigiditeit.
De oplossing
De oplossing vereist dat de programmeur de invariant handhaaft dat elke mutabele referentie &mut T die vanuit de ruwe pointer van UnsafeCell is geproduceerd, de enige actieve toegangspad tot dat geheugen moet zijn voor de gehele levensduur. Deze exclusiviteit verbiedt gelijktijdige lezingen of schrijvingen via enige andere pointer, referentie of opeenvolgende aanroepen van get() tijdens het bestaan van de mutabele referentie. UnsafeCell schakelt de borrow checker niet uit; het draagt eenvoudigweg de verantwoordelijkheid voor het waarborgen van temporele exclusiviteit en het voorkomen van gegevensraces over van de compiler naar de ontwikkelaar.
Probleem beschrijving
We waren een high-throughput metrics aggregator aan het architecturen voor een low-latency handelssysteem waarbij meerdere threads de tellers bijwerkten die aan specifieke financiële instrumenten waren gekoppeld. De gedeelde kaart was immutabel na initiële configuratie, maar de metrische waarden vereisten frequente verhogingen. Het gebruik van Mutex<u64> introduceerde onaanvaardbare contentie, terwijl AtomicU64 onvoldoende bleek voor complexe samengestelde metrische types. We hadden lock-vrije, nul-allocatie updates nodig voor structs achter Arc pointers zonder runtime borrow checks.
Verschillende oplossingen overwogen
Oplossing 1: Sharded Mutexes
We evalueerden het verpakken van elke metriek in een Mutex en deze over 256 shards te verdelen om de contentie te verminderen. Deze aanpak bood directe veiligheid en eenvoudige, onderhoudbare code. Profilering toonde echter aan dat zelfs onbetwiste Mutex-operaties honderden nanoseconden in beslag namen door futex syscalls en cache coherent protokollen, wat onze strikte sub-microseconde latentiebudget schond.
Oplossing 2: AtomicPtr met Boxed Waarden
Een andere benadering was om waarden op te slaan als AtomicPtr<Metric> en vergelijk-en-vervang-lussen te gebruiken voor updates. Dit elimineerde blokkeren, maar vereiste het toewijzen van nieuwe Box-instanties voor elke verhoging, wat leidde tot ernstige geheugendruk en allocator contentie. Bovendien compliceerde het het terugwinnen van geheugen, wat hazard pointers of epoch-gebaseerde garbage collection vereiste die de codecomplexiteit en audit oppervlakte aanzienlijk verhoogde.
Oplossing 3: UnsafeCell met Cache-Line Alignement
We kozen ervoor om metrieken in UnsafeCell<Metric> op te slaan binnen cache-line-aligned structs, waardoor threads die naar verschillende shards schrijven nooit cache lijnen delen. Elke thread verkreeg een ruwe pointer via UnsafeCell::get(), castte het naar &mut Metric tijdens de update—garandeerd veilig door onze sharding logica die ervoor zorgde dat geen andere thread dat specifieke slot kon benaderen—en voerde de mutatie uit. Dit vereiste unsafe blokken en een formeel bewijs dat onze consistente hashing ervoor zorgde dat er geen botsingen optraden tijdens gelijktijdige toegang.
Welke oplossing werd gekozen en waarom
We selecteerden Oplossing 3 omdat het een nul-kosten abstractie over ruwe geheugen bood terwijl het voldeed aan de agressieve latentie-eisen. De sharding garantie fungeerde als een handmatig bewijs van exclusieve toegang, waarmee we UnsafeCell konden gebruiken zonder runtime synchronisatie overhead. We valideerden de veiligheid met MIRI en de loom concurrentiemodelchecker om uitputtend te verifiëren dat er geen aliasing schendingen optraden onder alle mogelijke thread-interleavings.
Resultaat
De implementatie bereikte sub-100 nanoseconde update latenties met nul allocaties in het hete pad. Echter, een subtiele regressie deed zich voor tijdens een daaropvolgende refactoring waarbij een onderhoudstaak per ongeluk over alle shards iterede zonder de impliciete shard-lock te verwerven, waardoor twee mutabele referenties naar dezelfde metriek werden gecreëerd. MIRI gaf dit onmiddellijk aan als ongedefinieerd gedrag tijdens CI, wat versterkte dat UnsafeCell rigoureuze discipline vereist, zelfs wanneer het architectonische ontwerp theoretisch veiligheid garandeert.
Waarom is het ongedefinieerd gedrag om tegelijkertijd twee mutabele referenties afgeleid van een UnsafeCell te hebben, hoewel UnsafeCell zich expliciet onttrekt aan de standaard borrow regels?
UnsafeCell onttrekt zich aan de onveranderlijkheidsgarantie voor gedeelde referenties op het type-niveau, maar het verlicht de fundamentele invariant van het &mut T type zelf niet. Wanneer je get() aanroept, ontvang je een ruwe pointer *mut T die geen levensduur of aliasing beperkingen met zich meebrengt. Echter, op het moment dat je deze pointer dereferentieert naar een &mut T, geef je aan de compiler aan dat deze referentie exclusief is. Het creëren van twee dergelijke referenties naar overlappend geheugen, zelfs vanuit dezelfde UnsafeCell,schendt de aliasing XOR mutatie regel die de geheugenmodel van Rust onderbouwt, wat leidt tot onmiddellijk ongedefinieerd gedrag, ongeacht hoe de referenties zijn geconstrueerd.
Hoe detecteert MIRI schendingen van de UnsafeCell-invarianties, en waarom kan code productie-tests doorstaan maar falen onder MIRI?
MIRI implementeert het Stacked Borrows (of optioneel Tree Borrows) aliasingmodel, dat de toegang tot geheugenbeheer door abstracte "tags" bijhoudt. Wanneer je een referentie van een UnsafeCell maakt, wijst MIRI een unieke tag toe. Elke poging om een andere tag te gebruiken om hetzelfde geheugen te benaderen terwijl de eerste referentie actief is, vormt een schending. Code slaagt vaak voor standaardtests omdat hardwaregeheugenmodellen vergevingsgezind zijn, en goedaardige gegevensraces misschien niet als crashes manifesteren in de praktijk. MIRI, echter, handhaaft rigoureus het theoretische model, en pakt overtredingen zoals het ongeldig maken van een mutabele referentie door het maken van een gedeelde referentie vanuit dezelfde UnsafeCell zonder de juiste synchronisatie, zelfs als de assemblage toevallig werkt op de huidige CPU-architectuur.
Leg uit waarom Cell<T> geen onveilige blokken vereist voor mutatie terwijl UnsafeCell<T> dat wel doet, en identificeer de specifieke veiligheidswaarborg die dit onderscheid mogelijk maakt.
Cell<T> bereikt interne mutabiliteit zonder unsafe door nooit referenties naar zijn interne gegevens bloot te stellen; het staat alleen het kopiëren van waarden in (set) of uit (get) toe voor types die Copy implementeren, of het verplaatsen ervan (replace) voor niet-Copy types. Omdat Cell nooit een &T of &mut T aan de bevatwaarden oplevert, is het onmogelijk om de aliasingregels te schenden—er zijn geen referenties om te aliasen. UnsafeCell, daarentegen, biedt get() dat een ruwe pointer *mut T retourneert, wat het creëren van referenties mogelijk maakt. Deze flexibiliteit is nodig voor complexe in-place mutaties, maar verlegt de last van het waarborgen van exclusiviteit en het voorkomen van gegevensraces volledig naar de programmeur, wat onveilige blokken vereist.