Rust introduceert auto traits—zoals Send en Sync—om de ergonomische last van het handmatig bewijzen van thread-veiligheid voor elk samenstellend type op te lossen. Historisch gezien moesten systeemprogrammeurs elke struct annoteren met complexe gelijktijdigheidscontracten, wat foutgevoelig en omslachtig was. De compiler lost dit op door deze traits automatisch te implementeren voor aggregatietypen (structs, enums, tuples) als en alleen als al hun samenstellende velden ze implementeren.
Het probleem doet zich voor met ruwe pointers (*const T en *mut T). In tegenstelling tot referenties of slimme pointers, dragen ruwe pointers geen eigendom of aliaseringsemantiek die de compiler kan verifiëren. Ze kunnen wijzen naar thread-lokale opslag, niet-toegewezen geheugen of gedeelde wijzigbare status die wordt beheerd via externe synchronisatie. Blind Send of Sync toepassen op ruwe pointers alleen op basis van T zou de geheugenveiligheid schenden, aangezien de compiler niet kan garanderen dat de pointer correct wordt gebruikt over thread-grenzen.
De oplossing splitst de afleidingslogica. Voor aggregaten voert de compiler structurele recursie uit: hij controleert elk veld. Voor ruwe pointers houdt de compiler deze implementaties expliciet in, en behandelt ze als ondoorzichtige, potentieel onveilige handvatten. Dit dwingt ontwikkelaars om unsafe impl Send of unsafe impl Sync te gebruiken, en daarmee de persoonlijke verantwoordelijkheid te nemen voor het handhaven van de thread-veiligheidsgaranties die de compiler niet kan afleiden.
use std::ptr::NonNull; // Een aggregatietype struct Container<T> { data: Vec<T>, // Vec<T> is Send als T Send is index: usize, } // Container<T> is automatisch Send als T: Send // Een type met een ruwe pointer struct Node<T> { value: T, next: *mut Node<T>, // Ruwe pointer doorbreekt auto-afleiding } // Expliciete opt-in vereist unsafe impl<T: Send> Send for Node<T> {} unsafe impl<T: Sync> Sync for Node<T> {}
Tijdens de ontwikkeling van een nul-allocatie, lock-vrije MPMC (multi-producer, multi-consumer) ringbuffer voor een high-frequency trading applicatie, had ik nodes nodig die zich in een vooraf toegewezen array bevonden om jemalloc contentie te vermijden. De Node struct bevatte de payload en een *mut Node<T> volgende pointer, die een intrusieve gekoppelde lijst vormde. Bij het proberen om de bufferhandle naar een worker thread te verzenden, wees de compiler de code af omdat Node niet Send implementeerde, ondanks mijn kennis dat nodes alleen toegankelijk waren via atomische vergelijk-en-wissel operaties.
Ik evalueerde drie oplossingen. Ten eerste, het vervangen van de ruwe pointer door Box<Node<T>>. Dit werd verworpen omdat Box impliciet eigendom van de heap en individuele allocaties impliceert, wat de cache-vriendelijke ringbuffer fragmenteerde en allocatietijd introduceerde die onaanvaardbaar was in HFT. Ten tweede, het gebruik van NonNull<Node<T>> verpakt in AtomicPtr. Terwijl AtomicPtr zelf Send is als T Send is, faalde de omhullende Node struct nog steeds in auto-afleiding omdat de ruwe pointer binnen NonNull (wat een omhulsel rond een ruwe pointer is) de structurele controle blokkeerde. Ten derde, handmatig Send en Sync implementeren met behulp van unsafe impl blokken.
Ik koos voor de derde aanpak nadat ik formeel had geverifieerd dat alle toegang tot de next pointer beschermd was door SeqCst atomische operaties op een aparte statusindex, waardoor ervoor werd gezorgd dat zogenaamde happens-before relaties gegevensraces voorkwamen. Deze oplossing behoudt de lock-vrije, nul-allocatie architectuur terwijl het voldoet aan Rust's typesysteem. Het resultaat was een productieklare wachtrij die miljoenen gebeurtenissen per seconde kon verwerken zonder mutex overhead, hoewel het uitgebreide SAFETY opmerkingen vereiste voor toekomstige onderhouders.
Waarom implementeert een ruwe pointer naar een Send-type niet automatisch Send?
Kandidaten gaan vaak ervan uit dat Send "transitief" is door alle velden, inclusief ruwe pointers. Ze vergeten te erkennen dat ruwe pointers primitieve types zijn zonder intrinsieke eigendomsemantiek. De compiler kan niet onderscheid maken tussen een pointer naar thread-lokale opslag en een pointer naar gedeeld heap-geheugen, noch kan het verificatie van aliasingregels. Gevolg is dat *const T en *mut T nooit automatisch Send of Sync implementeren, ongeacht T, wat de programmeur dwingt om unsafe impl te gebruiken om verantwoordelijkheid te nemen voor het thread-veiligheid contract van de pointer.
Hoe kan ik conditioneel Send implementeren voor een generieke struct met onveilige internals?
Veel ontwikkelaars veronderstellen dat unsafe impl onvoorwaardelijk moet zijn. In werkelijkheid kunt u unsafe impl<T> Send for MyType<T> where T: Send + 'static {} schrijven. Dit is essentieel voor generieke containers (zoals een aangepaste UnsafeCell omhulsel) die alleen Send moeten zijn wanneer hun inhoud dat is. Kandidaat mist dat de where clausule in een unsafe impl dezelfde expressieve kracht als veilige traits biedt, waardoor gegarandeerd wordt dat thread-veiligheid beperkingen correct door generieke code worden doorgegeven zonder de implementatie te overbeperken.
Wat onderscheidt de veiligheidseisen voor het implementeren van Sync versus Send op een type met ruwe pointers?
Send vereist alleen dat het overdragen van eigendom van de waarde over thread-grenzen veilig is. Voor een ruwe pointer betekent dit meestal dat het verplaatsen van het adres veilig is als de pointee Send is. Sync daarentegen vereist dat het delen van ongewijzigde referenties (&Self) over threads veilig is. Als &Node de ruwe pointerwaarde blootstelt (die dereferentieerbaar zou kunnen zijn), en een andere thread de pointee wijzigt via een wijzigbare referentie, vormt dit een gegevensrace. Daarom vereisen Sync implementaties voor types die ruwe pointers bevatten bijna altijd bewijs van gesynchroniseerde toegang (bijv. de pointer wordt alleen toegankelijk gemaakt onder een Mutex of via atomische operaties), terwijl Send misschien alleen bewijs vereist van unieke eigendomsoverdracht.