Rust führt Auto-Traits ein – wie Send und Sync – um die ergonomische Belastung der manuellen Nachweisführung von Thread-Sicherheit für jeden zusammengesetzten Typ zu lösen. Historisch gesehen mussten Systemprogrammierer jede Struktur mit komplexen Parallelitätsverträgen annotieren, was fehleranfällig und umständlich war. Der Compiler löst dies, indem er diese Traits automatisch für Aggregattypen (Strukturen, Enums, Tupel) implementiert, wenn und nur wenn alle ihre Bestandteile diese implementieren.
Das Problem tritt bei rohen Zeigern (*const T und *mut T) auf. Im Gegensatz zu Referenzen oder Smart-Pointern tragen rohe Zeiger keine Eigentums- oder Aliasierungssemantiken, die der Compiler überprüfen kann. Sie können auf thread-lokale Speicherung, nicht zugewiesenen Speicher oder gemeinsam verwalteten veränderlichen Zustand zugreifen, der über externe Synchronisierung verwaltet wird. Blindes Anwenden von Send oder Sync auf rohe Zeiger lediglich basierend auf T würde die Speicher-Sicherheit verletzen, da der Compiler nicht garantieren kann, dass der Zeiger über Thread-Grenzen hinweg korrekt verwendet wird.
Die Lösung teilt die Ableitungslogik auf. Für Aggregate führt der Compiler strukturelle Rekursion durch: Er überprüft jedes Feld. Für rohe Zeiger zieht der Compiler diese Implementierungen explizit zurück und behandelt sie als opake, potenziell unsichere Handles. Dies zwingt Entwickler dazu, unsafe impl Send oder unsafe impl Sync zu verwenden, was persönliche Verantwortung für die Einhaltung der Thread-Sicherheitsgarantien, die der Compiler nicht ableiten kann, bedeutet.
use std::ptr::NonNull; // Ein Aggregat-Typ struct Container<T> { data: Vec<T>, // Vec<T> ist Send, wenn T Send ist index: usize, } // Container<T> ist automatisch Send, wenn T: Send // Ein Typ mit einem rohen Zeiger struct Node<T> { value: T, next: *mut Node<T>, // Roher Zeiger bricht die automatische Ableitung } // Explizites Opt-in erforderlich unsafe impl<T: Send> Send for Node<T> {} unsafe impl<T: Sync> Sync for Node<T> {}
Während der Entwicklung eines null-allokierenden, lockfreien MPMC (multi-producer, multi-consumer) Ringpuffers für eine Hochfrequenzhandel-Anwendung musste ich sicherstellen, dass die Knoten in einem vorab zugewiesenen Array wohnen, um jemalloc-Konflikte zu vermeiden. Die Struktur Node enthielt die Nutzlast und einen *mut Node<T> nächsten Zeiger, der eine intrusive verkettete Liste bildete. Als ich versuchte, den Pufferspeicher an einen Arbeits-Thread zu senden, wies der Compiler den Code zurück, da Node nicht Send implementierte, obwohl ich wusste, dass Knoten nur über atomare Vergleichs-und-Tausch-Operationen zugegriffen wurden.
Ich bewertete drei Lösungen. Erstens, den rohen Zeiger durch Box<Node<T>> zu ersetzen. Dies wurde abgelehnt, da Box Heap-Eigentum und individuelle Allokationen impliziert, was den cachefreundlichen Ringpuffer fragmentierte und eine Allokations-Latenz einführte, die im HFT nicht akzeptabel war. Zweitens, die Verwendung von NonNull<Node<T>>, das in AtomicPtr eingewickelt ist. Während AtomicPtr selbst Send ist, wenn T Send ist, scheiterte die enthaltene Struktur Node immer noch an der automatischen Ableitung, da der rohe Zeiger innerhalb von NonNull (der ein Wrapper um einen rohen Zeiger ist) die strukturelle Überprüfung blockierte. Drittens, die manuelle Implementierung von Send und Sync unter Verwendung von unsafe impl Blöcken.
Ich wählte den dritten Ansatz, nachdem ich formal verifiziert hatte, dass alle Zugriffe auf den next-Zeiger von SeqCst-atomaren Operationen auf einem separaten Zustandsindex geschützt waren, wodurch sichergestellt wurde, dass die Happens-Before-Beziehungen Datenrennen verhinderten. Diese Lösung bewahrte die lockfreie, null-allokierende Architektur und erfüllte die Typensystemanforderungen von Rust. Das Ergebnis war eine produktionsreife Warteschlange, die Millionen von Ereignissen pro Sekunde ohne Mutex-Overhead verarbeiten konnte, obwohl es umfangreiche SAFETY-Kommentare für zukünftige Wartende erforderte.
Warum implementiert ein roher Zeiger auf einen Send-Typ nicht automatisch Send?
Kandidaten gehen häufig davon aus, dass Send "transitiv" durch alle Felder ist, einschließlich roher Zeiger. Sie erkennen nicht, dass rohe Zeiger primitive Typen ohne intrinsische Eigentumssemantiken sind. Der Compiler kann zwischen einem Zeiger auf thread-lokale Speicherung und einem Zeiger auf gemeinsam genutzten Heap-Speicher nicht unterscheiden, noch kann er Alias-Regeln überprüfen. Folglich implementieren *const T und *mut T niemals automatisch Send oder Sync, unabhängig von T, was den Programmierer zwingt, unsafe impl zu verwenden, um die Verantwortung für den Thread-Sicherheitsvertrag des Zeigers zu übernehmen.
Wie kann ich Send bedingt für eine generische Struktur mit unsicheren Interna implementieren?
Viele Entwickler gehen davon aus, dass unsafe impl bedingungslos sein muss. In Wirklichkeit können Sie unsafe impl<T> Send für MyType<T> where T: Send + 'static {} schreiben. Dies ist wichtig für generische Container (wie einen benutzerdefinierten UnsafeCell-Wrapper), die nur dann Send sein sollten, wenn ihre Inhalte dies sind. Kandidaten übersehen, dass die where-Klausel in einer unsafe impl die gleiche Ausdruckskraft wie sichere Traits ermöglicht, was sicherstellt, dass die Thread-Sicherheitsanforderungen korrekt durch generischen Code propagiert werden, ohne die Implementierung übermäßig einzuschränken.
Was unterscheidet die Sicherheitsanforderungen für die Implementierung von Sync gegenüber Send für einen Typ mit rohen Zeigern?
Send erfordert lediglich, dass der Besitz des Wertes über die Thread-Grenzen hinweg sicher übertragen werden kann. Für einen rohen Zeiger bedeutet dies normalerweise, dass das Verschieben des Adresswertes sicher ist, wenn der Zeigerwert Send ist. Sync hingegen erfordert, dass das Teilen von unveränderlichen Referenzen (&Self) über Threads hinweg sicher ist. Wenn &Node den rohen Zeigerwert (der dereferenziert werden könnte) exponiert und ein anderer Thread den Zeigerwert über eine veränderliche Referenz ändert, führt dies zu einem Datenrennen. Daher erfordern Sync-Implementierungen für Typen mit rohen Zeigern fast immer den Nachweis eines synchronisierten Zugriffs (z. B. der Zeiger wird nur unter einem Mutex oder über atomare Operationen zugegriffen), während Send möglicherweise nur den Nachweis eines einzigartigen Eigentumsübergangs erfordert.