Rust introduit des auto traits—comme Send et Sync—pour résoudre le fardeau ergonomique de prouver manuellement la sécurité des threads pour chaque type composite. Historiquement, les programmeurs systèmes devaient annoter chaque struct avec des contrats de concurrence complexes, ce qui était sujet à erreurs et verbeux. Le compilateur résout cela en implémentant automatiquement ces traits pour les types agrégés (structs, énumérations, tuples) uniquement si tous leurs champs constitutifs les implémentent.
Le problème se pose avec les pointeurs bruts (*const T et *mut T). Contrairement aux références ou aux pointeurs intelligents, les pointeurs bruts n'ont aucune sémantique de propriété ou d'aliasing que le compilateur peut vérifier. Ils peuvent pointer vers un stockage local au thread, une mémoire non allouée ou un état mutable partagé géré par une synchronisation externe. Appliquer aveuglément Send ou Sync aux pointeurs bruts uniquement en se basant sur T violerait la sécurité mémoire, car le compilateur ne peut garantir que le pointeur est utilisé correctement à travers les frontières de thread.
La solution bifurque la logique de dérivation. Pour les agrégats, le compilateur effectue une récursion structurelle : il vérifie chaque champ. Pour les pointeurs bruts, le compilateur s'abstient explicitement ces implémentations, les traitant comme des poignées opaques et potentiellement non sécurisées. Cela oblige les développeurs à utiliser unsafe impl Send ou unsafe impl Sync, prenant la responsabilité personnelle de maintenir les garanties de sécurité des threads que le compilateur ne peut pas inférer.
use std::ptr::NonNull; // Un type agrégé struct Container<T> { data: Vec<T>, // Vec<T> est Send si T est Send index: usize, } // Container<T> est automatiquement Send si T: Send // Un type avec un pointeur brut struct Node<T> { value: T, next: *mut Node<T>, // Le pointeur brut rompt la dérivation automatique } // Opt-in explicite requis unsafe impl<T: Send> Send for Node<T> {} unsafe impl<T: Sync> Sync for Node<T> {}
Lors du développement d'un tampon circulaire MPMC (multi-producteur, multi-consommateur) sans allocation et sans verrouillage pour une application de trading haute fréquence, j'avais besoin que les nœuds résident dans un tableau pré-alloué pour éviter la contention jemalloc. La struct Node contenait la charge utile et un pointeur *mut Node<T> suivant formant une liste chaînée intrusive. En essayant d'envoyer le gestionnaire du tampon à un thread de travail, le compilateur a rejeté le code parce que Node n'implémentait pas Send, malgré ma connaissance que les nœuds n'étaient accessibles qu'à travers des opérations atomiques de comparaison et d'échange.
J'ai évalué trois solutions. D'abord, remplacer le pointeur brut par Box<Node<T>>. Cela a été rejeté car Box implique une propriété de tas et des allocations individuelles, ce qui fragmentait le tampon circulaire amical avec le cache et introduisait une latence d'allocation inacceptable dans HFT. Deuxièmement, utiliser NonNull<Node<T>> enveloppé dans AtomicPtr. Bien que AtomicPtr lui-même soit Send si T est Send, la struct contenant Node échouait toujours à la dérivation automatique parce que le pointeur brut à l'intérieur de NonNull (qui est un enveloppe autour d'un pointeur brut) bloquait la vérification structurelle. Troisièmement, implémenter manuellement Send et Sync en utilisant des blocs unsafe impl.
J'ai choisi la troisième approche après avoir vérifié formellement que tous les accès au pointeur next étaient protégés par des opérations atomiques SeqCst sur un index d'état distinct, assurant que les relations de happens-before empêchaient les courses de données. Cette solution préservait l'architecture sans verrouillage et sans allocation tout en satisfaisant le système de types de Rust. Le résultat était une file de production capable de traiter des millions d'événements par seconde sans surcharge de mutex, bien qu'elle ait nécessité des commentaires « SAFETY » extensifs pour les futurs mainteneurs.
Pourquoi un pointeur brut vers un type Send n'implémente-t-il pas automatiquement Send ?
Les candidats supposent fréquemment que Send est "transitif" à travers tous les champs, y compris les pointeurs bruts. Ils ne reconnaissent pas que les pointeurs bruts sont des types primitifs sans sémantique de propriété intrinsèque. Le compilateur ne peut pas distinguer entre un pointeur vers un stockage local au thread et un pointeur vers une mémoire partagée sur le tas, ni vérifier les règles d'aliasing. Par conséquent, *const T et *mut T n'implémentent jamais Send ou Sync automatiquement, quel que soit T, obligeant le programmeur à utiliser unsafe impl pour prendre la responsabilité du contrat de sécurité des threads du pointeur.
Comment puis-je implémenter conditionnellement Send pour un struct générique contenant des internes non sécurisés ?
De nombreux développeurs supposent que unsafe impl doit être inconditionnel. En réalité, vous pouvez écrire unsafe impl<T> Send pour MyType<T> où T: Send + 'static {}. C'est essentiel pour les conteneurs génériques (comme un wrapper UnsafeCell personnalisés) qui ne devraient être Send que lorsque leurs contenus le sont. Les candidats manquent le fait que la clause where dans un unsafe impl permet la même puissance expressive que les traits sûrs, garantissant que les contraintes de sécurité des threads se propagent correctement à travers le code générique sans sur-contraindre l'implémentation.
Qu'est-ce qui distingue les exigences de sécurité pour implémenter Sync par rapport à Send sur un type avec des pointeurs bruts ?
Send exige seulement que le transfert de propriété de la valeur à travers les frontières des threads soit sûr. Pour un pointeur brut, cela signifie généralement que déplacer la valeur d'adresse est sûr si le pointeur est Send. Sync, en revanche, exige que partager des références immuables (&Self) à travers les threads soit sûr. Si &Node expose la valeur du pointeur brut (qui pourrait être déréférencé), et qu'un autre thread modifie le pointeur à travers une référence mutable, cela constitue une course de données. Par conséquent, les implémentations Sync pour des types contenant des pointeurs bruts nécessitent presque toujours la preuve d'un accès synchronisé (par exemple, le pointeur n'est accessible que sous un Mutex ou via des opérations atomiques), tandis que Send peut seulement nécessiter la preuve d'un transfert de propriété unique.