Arc::make_mut versucht, einen mutablen Zugriff auf die inneren Daten zu ermöglichen, indem zuerst überprüft wird, ob die Arc die einzige starke Referenz auf die Zuweisung hält. Diese Überprüfung erfolgt mit einem atomaren Ladevorgang mit Acquire-Anordnung auf den starken Referenzzähler. Wenn der Zähler genau eins beträgt, wird die Operation fortgesetzt, um eine mutable Referenz zurückzugeben; andernfalls wird die innere Datenstruktur kopiert und die Arc aktualisiert, um auf die neue Zuweisung zu zeigen.
use std::sync::Arc; let mut data = Arc::new(5); *Arc::make_mut(&mut data) += 1; // Klone nur, wenn geteilt
Das Acquire/Release-Paar ist entscheidend, da ein anderer Thread, der seine Arc fallen lässt, eine Release-Decrement auf dem Zähler durchführt. Der Acquire-Ladevorgang in make_mut stellt sicher, dass alle von dem auflösenden Thread vor dem Decrement vorgenommenen Speicheränderungen für den aktuellen Thread sichtbar sind, wodurch Datenrennen auf den inneren Daten verhindert werden.
Betrachten wir einen Hochdurchsatz-Metrikaggregationsdienst, bei dem Konfigurationsänderungen über Arc<Config> propagiert werden. Tausende von Threads halten Referenzen, um die aktuellen Einstellungen zu lesen, aber der Admin-Thread muss periodisch Schwellenwerte anpassen, ohne den Dienst neu zu starten.
Der naive Ansatz besteht darin, die Config in ein RwLock zu wickeln und es für jeden Lesevorgang zu sperren oder die gesamte Struktur für jede kleinere Aktualisierung unabhängig von der Teilung zu kopieren. Die erste Lösung leidet unter Cache-Line-Bouncing und Sperre-Overhead, während die zweite Speicher und CPU-Zyklen für redundante Zuweisungen verschwendet, wenn die Konfiguration tatsächlich einzigartig ist.
Eine Alternative besteht darin, AtomicPtr mit Hazard Pointern für sperrfrei Updates zu verwenden, was jedoch eine komplexe manuelle Speicherverwaltung erfordert und fehleranfällig ist. Eine weitere Option ist die Verwendung von RwLock<Arc<Config>>, die atomare Tausche des Zeigers selbst ermöglicht, aber eine zusätzliche Indirektion und Sperre für den Zeigerwechsel hinzufügt.
Das Team wählte Arc::make_mut, weil es den häufigen Fall optimiert: Wenn kein anderer Thread eine Referenz hält (starker Zähler ist 1), ändert der Admin-Thread die Daten vor Ort ohne Zuweisung. Wenn die Konfiguration geteilt ist, wird sie transparent kopiert. Dies erfordert die strengen Acquire/Release-Semantiken, um sicherzustellen, dass, wenn der letzte andere Leser seine Arc fallen lässt (unter Verwendung von Release), der anschließende Check des Admin-Threads (unter Verwendung von Acquire) alle vorherigen Schreibvorgänge an der Konfiguration sieht, wodurch zerrissene Lesevorgänge verhindert werden. Das Ergebnis war eine 40%ige Reduzierung der Latenz für Konfigurationsupdates unter geringer Konkurrenz.
Warum kann die Relaxed Anordnung nicht für die Überprüfung des Referenzzählers in Arc::make_mut verwendet werden?
Relaxed-Operationen bieten keine Happens-before-Garantien. Wenn make_mut Relaxed verwendet hätte, um zu überprüfen, ob der starke Zähler 1 ist, könnte es den Zählerdecrement von einem anderen Thread vor der Beobachtung der Schreibvorgänge dieses Threads an den inneren Daten sehen. Dies würde es dem aktuellen Thread ermöglichen, die Daten zu verändern, während ein anderer Thread diese logisch noch liest, wodurch ein Datenrennen entstehen würde. Acquire stellt sicher, dass, wenn wir sehen, dass der Zähler 1 erreicht, wir auch alle vorherigen Schreibvorgänge an den Daten sehen.
Was unterscheidet das Verhalten von Arc::make_mut vom manuellen Klonen der Arc mit .clone() gefolgt von einer Modifikation?
Das manuelle Klonen erstellt eine neue Arc, die auf dieselbe Zuweisung zeigt, wodurch der starke Zähler auf mindestens 2 erhöht wird. Sie können keinen mutablen Zugriff auf die inneren Daten über diese neue Arc erhalten, da Arc nur unveränderliches Teilen bietet. Arc::make_mut ist besonders, weil es überprüft, ob der Zähler 1 ist; wenn ja, gibt es &mut T für die bestehende Zuweisung. Andernfalls wird die Daten in eine neue Zuweisung mit einem Zähler von 1 kopiert, was sicherstellt, dass die ursprünglichen gemeinsam genutzten Daten unveränderlich bleiben, während Sie einzigartiges Eigentum an der neuen Kopie erhalten.
Wie beeinflussen schwache Zeiger (Arc::downgrade) die Einzigartigkeit der Garantien von Arc::make_mut?
Schwache Zeiger nehmen nicht am starken Referenzzähler teil. Arc::make_mut überprüft nur den starken Zähler und ignoriert schwache Referenzen. Schwache Zeiger können jedoch auf starke Zeiger aufgerüstet werden, wenn die Zuweisung noch existiert. Wenn make_mut mit einer In-Place-Modifikation fortfährt (starker Zähler ist 1), und ein anderer Thread anschließend einen schwachen Zeiger aufrüstet, wird dieses Upgrade eine neue Arc erstellen, die auf dieselben modifizierten Daten zeigt. Dies ist sicher, weil das Upgrade nach der Modifikation erfolgt, und das Speichermodell von Rust garantiert, dass der aufgerüstete Zeiger den vollständig modifizierten Wert sieht. Der schwache Zähler verhindert keine Modifikation, hält jedoch die Zuweisung am Leben, selbst wenn alle starken Referenzen vorübergehend fallen gelassen werden.