Historisch gesehen führte Rust Rc (Referenzzählung) als eine leistungsbewusste Alternative zu Arc (atomare Referenzzählung) für Single-Thread-Szenarien ein. Frühere Versionen der Sprache hatten diese Unterscheidung nicht, was alle gemeinsam genutzten Besitztümer zwang, die Kosten atomarer Operationen zu tragen. Die Auto-Traits Send und Sync wurden entworfen, um die Thread-Sicherheit kompositionell durchzusetzen, sodass der Compiler diese Eigenschaften automatisch basierend auf den Bestandteilen eines Typs ableiten kann.
Das Kernproblem liegt in der internen Implementierung von Rc, die einen nicht-atomaren Zähler (typischerweise in Cell<usize> oder UnsafeCell<usize> verpackt) verwendet, um aktive Referenzen zu verfolgen. Dieses Design geht von einem Single-Thread-Zugriff aus, um die Überheadkosten von Speicherbarrieren zu vermeiden. Wenn Rc<T> die Implementierung von Send gestattet wäre, könnte ein Programm eine Kopie des Zeigers in einen anderen Thread verschieben. Bei der Zerstörung oder dem Klonen im neuen Thread würden beide Threads unsynchronisierte Lese-Änderungs-Schreiboperationen auf die Referenzanzahl durchführen. Dies stellt ein Datenrennen dar, das potenziell die Zählung korrumpiert, was zu vorzeitiger Deallokation (use-after-free) oder Speicherlecks (double-free) führen kann.
Die Lösung ist architektonisch: Rc verzichtet ausdrücklich auf Send und Sync, indem es Typen enthält, die nicht thread-sicher sind (oder durch negative Implementierungen in modernem Rust). Dies zwingt Entwickler dazu, Arc<T> für die Thread-übergreifende Nutzung zu verwenden, das AtomicUsize für seine Zähler einsetzt und sicherstellt, dass Inkrement- und Dekrementoperationen atomar und korrekt über alle CPU-Kerne sequenziert sind. Der Compiler erzwingt diese Unterscheidung auf der Typ-Ebene und verhindert versehentliches Sharing ohne Laufzeitprüfungen.
Betrachten Sie einen hochleistungsfähigen Texteditor, der ein großes Dokument in einen abstrakten Syntaxbaum (AST) parst. Der Parser verwendet Rc<Node>, um geteilte Unterzeichenfolgen (z. B. identische Bezeichner) über den Baum hinweg darzustellen und optimiert den Speicher während der Single-Thread-Parsing-Phase. Es entsteht die Anforderung, die semantische Validierung zu parallelisieren, indem Teilbäume an einen Thread-Pool verteilt werden.
Das unmittelbare Problem besteht darin, dass die Kompilierung fehlschlägt, wenn versucht wird, Rc<Node> an Arbeitsthreads zu senden. Mehrere Lösungen wurden evaluiert:
Globale Ersetzung durch Arc: Alle Rc-Instanzen durch Arc ersetzen. Vorteile: Minimale Codeänderungen und sofortige Thread-Sicherheit. Nachteile: Das Profiling zeigte eine 12-15%ige Durchsatzminderung während des Parsings aufgrund unnötiger atomarer Operationen im heißen Pfad, was die Leistungsbudgets verletzte.
Tiefe Klonierung für Übertragung: Serialisierung von Teilbäumen in Vec<u8, Senden von Bytes und Deserialisieren auf Arbeitern. Vorteile: Kein unsicherer Code oder architektonische Änderungen. Nachteile: Hohe Latenz und CPU-Kosten für das Marshaling komplexer Graphstrukturen mit internen Zyklen, was es für die Echtzeitbearbeitung prohibitiv macht.
Unsichere Zeigerextraktion: Transmutieren von Rc in einen Rohzeiger, Senden des Zeigers und Rekonstruktion von Rc beim Empfänger. Vorteile: Null-Kopier-Überhead. Nachteile: Fundamental unsicher; verletzt das Besitz-Invarianz von Rc (der empfangende Thread kann nicht wissen, ob der sendende Thread seine Klone verwirft), was unvermeidlich zu Speicherbeschädigung oder schwebenden Zeigern führt.
Aufgabenverteilung basierend auf Kanälen: Beibehaltung des AST im Hauptthread und Senden leichter Validierungsaufgaben (Byte-Bereiche oder Knoten-Indizes) über crossbeam-Kanäle. Arbeiter geben Ergebnisse zurück, ohne den von Rc verwalteten Speicher zu berühren. Vorteile: Bewahrt die Rc-Leistung für das Parsing, beseitigt Datenrennen ohne unsafe und entkoppelt Komponenten. Nachteile: Erfordert eine Umstrukturierung des Validierungsalgorithmus von Datenparallelität zu Aufgabenparallelität.
Das Team wählte den ansatz, der auf Kanälen basiert. Der Parser blieb Single-Thread und schnell, während die Validierung linear mit der Anzahl der Kerne skalierte. Das Ergebnis war ein stabiles System ohne unsafe-Blöcke und mit erhaltenen Leistungsmerkmalen.
Warum bleibt Rc<T> !Sync, selbst wenn der umschlossene Typ T Sync ist, und wie unterscheidet sich dies von der Send-Einschränkung?
Rc<T> kann nicht Sync sein, weil unveränderliche Referenzen (&Rc<T>) die Verwendung von .clone() erlauben, was die interne nicht-atomare Referenzanzahl ändert. Selbst wenn T selbst sicher zu teilen ist (Sync), würde das Teilen des Rc-Wrappers über Threads hinweg gleichzeitige Inkremente des Zählers aus mehreren Threads erlauben, was ein Datenrennen verursacht. Die Send-Einschränkung verhindert vollständig, dass das Eigentum zu einem anderen Thread verschoben wird, während die Sync-Einschränkung sogar das Teilen von Referenzen über Threads hinweg verhindert. Rc verletzt beide Prinzipien, da seine "schreibgeschützten" Operationen (Klonen) tatsächlich interne Modifikationen durchführen.
*Wie beeinflusst PhantomData<T> die automatische Ableitung von Send und Sync für eine benutzerdefinierte Struktur, die einen Rohzeiger (const T) umschließt, und warum ist seine Einbeziehung entscheidend?
Ohne PhantomData trägt eine Struktur, die *const T enthält, keine Typinformation, die sie für die Ableitung der Auto-Traits mit T verknüpft. Der Compiler geht vorsichtshalber davon aus, dass der Zeiger schwebend sein könnte, beliebig aliasieren oder auf thread-lokale Daten zeigen könnte, und verweigert daher die Ableitung von Send oder Sync. Durch die Einbeziehung von PhantomData<T> signalisiert der Entwickler dem Compiler, dass die Struktur logisch ein T besitzt. Folglich implementiert die Struktur automatisch Send, wenn T: Send und Sync, wenn T: Sync, was die kompositionale Thread-Sicherheit für FFI-Wrappers oder benutzerdefinierte Smart Pointer wiederherstellt.
Unter welchen spezifischen Bedingungen verliert ein Trait-Objekt Box<dyn Trait> das Send-Auto-Trait, selbst wenn der zugrunde liegende konkrete Typ Send implementiert?
Ein Trait-Objekt dyn Trait implementiert nur Send, wenn die Trait-Definition ausdrücklich Send als Obergrenze erfordert (z. B. trait Trait: Send). Wenn der konkrete Typ in ein Trait-Objekt verschleiert wird, verwirft der Compiler alle spezifischen Typinformationen, einschließlich der Implementierungen von Auto-Traits. Sofern der Trait selbst nicht die Gewähr für Send-Eigenschaften bietet, kann der Compiler nicht überprüfen, ob die vtable auf thread-sichere Methoden zeigt. Dies verhindert, dass boxed Trait-Objekte über Thread-Grenzen hinweg gesendet werden können, es sei denn, die Trait-Bindung schließt ausdrücklich Send (und Sync) ein, wodurch die Objektsicherheit effektiv auf thread-sichere Implementierungen beschränkt wird.