Arc::make_mut probeert mutatieve toegang tot de interne gegevens te bieden door eerst te verifiëren dat de Arc de enige sterke referentie naar de toewijzing heeft. Het voert deze controle uit met een atomische laadopdracht met Acquire synchronisatie op de sterke referentietelling. Als de telling precies één is, gaat de bewerking verder met het retourneren van een mutabele referentie; anders kloont het de interne gegevens en werkt het de Arc bij om naar de nieuwe toewijzing te wijzen.
use std::sync::Arc; let mut data = Arc::new(5); *Arc::make_mut(&mut data) += 1; // Kloont alleen als gedeeld
De Acquire/Release paar is essentieel omdat wanneer een andere thread zijn Arc laat vallen, deze een Release decrement op de telling uitvoert. De Acquire laadopdracht in make_mut zorgt ervoor dat alle geheugenwrites die door de vallende thread vóór de decrement zijn gemaakt, zichtbaar zijn voor de huidige thread, waardoor dataraces op de interne gegevens worden voorkomen.
Beschouw een high-throughput metrics aggregatiedienst waar configuratie-updates via Arc<Config> worden verspreid. Duizenden threads houden referenties om huidige instellingen te lezen, maar de admin-thread moet periodiek drempels aanpassen zonder de dienst opnieuw te starten.
De naïeve benadering is om de Config in een RwLock te wikkelen en deze voor elke lezing te vergrendelen, of de hele structuur te klonen voor elke kleine update, ongeacht delen. De eerste oplossing heeft te maken met cache-line bouncing en lock overhead, terwijl de tweede geheugen en CPU-cycli verspilt aan overbodige toewijzingen wanneer de configuratie eigenlijk uniek is.
Een alternatief is het gebruik van AtomicPtr met hazard pointers voor lock-vrije updates, maar dit vereist complexe handmatige geheugenbeheer en is foutgevoelig. Een andere optie is om een RwLock<Arc<Config>> te gebruiken, wat atomische verwisselingen van de pointer zelf mogelijk maakt, maar dit voegt een extra indirectie en vergrendeling voor de pointer verwisseling toe.
Het team koos voor Arc::make_mut omdat het optimaliseert voor het veelvoorkomende geval: als geen andere thread een referentie houdt (de sterke telling is 1), wijzigt de admin-thread de gegevens in-place zonder toewijzing. Als de configuratie gedeeld is, kloont het transparant. Dit vereist de strikte Acquire/Release semantiek om ervoor te zorgen dat wanneer de laatste andere lezer zijn Arc laat vallen (met behulp van Release), de daaropvolgende controle van de admin-thread (met behulp van Acquire) alle eerdere writes naar de configuratie ziet, waardoor gescheurde leesoperaties worden voorkomen. Het resultaat was een vermindering van 40% in latentie voor configuratie-updates onder lage inhouding.
Waarom kan Relaxed synchronisatie niet worden gebruikt voor de referentietellingcontrole in Arc::make_mut?
Relaxed operaties bieden geen happens-before garanties. Als make_mut Relaxed zou gebruiken om te controleren of de sterke telling 1 is, zou het de telling kunnen waarnemen die door een andere thread is gedecrementeerd, voordat het de writes van die thread naar de interne gegevens waarneemt. Dit zou de huidige thread in staat stellen om de gegevens te muteren terwijl een andere thread nog steeds logisch aan het lezen is, wat een datarace zou veroorzaken. Acquire zorgt ervoor dat wanneer we de telling van 1 zien (gesynchroniseerd via de Release in de drop van de andere thread), we ook alle eerdere writes naar de gegevens zien.
Wat onderscheidt het gedrag van Arc::make_mut van handmatig klonen van de Arc met .clone() gevolgd door modificatie?
Handmatig klonen creëert een nieuwe Arc die naar dezelfde toewijzing wijst, waardoor de sterke telling tot minstens 2 toeneemt. Je kunt geen mutatieve toegang tot de interne gegevens krijgen via deze nieuwe Arc omdat Arc alleen immutabele delen biedt. Arc::make_mut is speciaal omdat het controleert of de telling 1 is; als dat zo is, biedt het &mut T aan voor de bestaande toewijzing. Als dat niet het geval is, kloont het de data naar een nieuwe toewijzing met een telling van 1, wat ervoor zorgt dat de originele gedeelde gegevens immutabel blijven, terwijl je unieke eigendom van de nieuwe kopie krijgt.
Hoe beïnvloeden zwakke pointers (Arc::downgrade) de uniciteitsgarantie van Arc::make_mut?
Zwakke pointers nemen niet deel aan de sterke referentietelling. Arc::make_mut controleert alleen de sterke telling, waarbij zwakke referenties worden genegeerd. Echter, zwakke pointers kunnen worden omgezet naar sterke als de toewijzing nog bestaat. Als make_mut doorgaat met in-place mutatie (sterke telling is 1), en een andere thread vervolgens een zwakke pointer omgezet, creëert die omvorming een nieuwe Arc die naar dezelfde gemuteerde gegevens wijst. Dit is veilig omdat de omvorming plaatsvindt na de mutatie, en Rust's geheugenmodel garandeert dat de omgevormde pointer de volledig gewijzigde waarde ziet. De zwakke telling voorkomt geen mutatie, maar houdt de toewijzing in leven, zelfs als alle sterke referenties tijdelijk zijn laten vallen.