Le concept de fossés de mémoire provient des modèles de mémoire matérielle où les CPU utilisent l'exécution hors ordre pour maximiser le débit. Rust's std::sync::atomic::fence expose ces primitives de bas niveau pour établir des contraintes d'ordre entre les opérations mémoire sur des emplacements distincts sans modifier les données. Contrairement aux opérations atomiques qui associent la modification des données avec des garanties d'ordre, les fossés agissent comme des barrières de synchronisation qui font respecter des règles de visibilité pour toutes les opérations mémoire précédentes ou suivantes.
Une idée reçue commune est que l'utilisation de Ordering::SeqCst sur une variable atomique synchronise automatiquement toutes les écritures antérieures vers des emplacements mémoire non liés entre les threads. C'est incorrect car SeqCst ne fournit qu'un ordre total pour les opérations atomiques elles-mêmes, et non une relation transitive happens-before pour d'autres données. Lorsque le fil A écrit dans un tampon et effectue ensuite un stockage Release sur un drapeau atomique, le fil B effectuant un chargement Acquire sur ce drapeau ne voit pas automatiquement les écritures du tampon à moins qu'un fossé ou un ordre plus fort ne lie les deux domaines.
Pour résoudre cela, fence(Ordering::Release) garantit que toutes les opérations mémoire la précédant dans l'ordre du programme deviennent visibles pour d'autres threads avant toute opération de stockage atomique subséquente. A l'inverse, fence(Ordering::Acquire) garantit que toutes les opérations mémoire qui suivent observant les valeurs écrites avant un fossé Release correspondant dans un autre fil. Cette synchronisation par paire crée une relation happens-before sur l'état mémoire entier, et pas seulement sur la variable atomique, permettant des algorithmes sans verrou qui s'appuient sur des canaux de contrôle et de données distincts.
Considérons un processeur de paquet réseau sans copie où un fil remplit un tampon circulaire partagé avec des données de paquet et met à jour un pointeur de tête, tandis qu'un autre fil lit le pointeur et traite les paquets. Le producteur écrit des octets de paquet dans le tampon à l'aide d'écritures standard (opérations non atomiques) puis incrémente atomiquement l'index de tête en utilisant Ordering::Release pour signaler la disponibilité de nouvelles données. Le consommateur attend que l'index change, puis lit les données du paquet à partir du tampon.
Une solution potentielle consistait à protéger l'ensemble du tampon et de l'index avec un std::sync::Mutex. Bien que cela garantisse la sécurité mémoire et la cohérence séquentielle, cela introduit une forte contention ; chaque écriture de paquet nécessite l'acquisition du verrou, sérialisant le producteur et détruisant la localité du cache. Cette approche a réduit le débit à des niveaux inacceptables pour les exigences de trading haute fréquence, rendant cela inadapté pour des systèmes à faible latence.
Une autre approche envisagée consistait à remplacer la paire Release/Acquire par Ordering::SeqCst pour le pointeur de tête, supposant que son ordre global flusherait implicitement les écritures du tampon. Cela échoue car SeqCst n'établit qu'un ordre total parmi les opérations SeqCst elles-mêmes ; le compilateur et le CPU restent libres de réorganiser les écritures non atomiques du tampon après le stockage atomique. Par conséquent, le consommateur pourrait observer un index de tête mis à jour tout en lisant des données de paquet obsolètes, violant la sécurité mémoire malgré l'ordre atomique apparemment fort.
La solution choisie a inséré un fence(Ordering::Release) après avoir terminé toutes les écritures du tampon mais avant de stocker l'index de tête mis à jour du côté producteur. Le fil consommateur a placé un fence(Ordering::Acquire) immédiatement après le chargement de l'index de tête et avant de déréférencer le pointeur du tampon. Cette paire garantit que les écritures du tampon sont globalement visibles avant la publication de la mise à jour de l'index, et le consommateur ne peut pas lire de manière spéculative le tampon jusqu'à ce que l'index soit synchronisé, éliminant les courses de données sans verrous.
Le résultat était une file d'attente SPSC (single-producer-single-consumer) sans verrou capable de traiter des millions de paquets par seconde avec une latence de microsecondes. Les benchmarks ont montré une amélioration décamétrique par rapport à l'approche basée sur le Mutex et aucune course de données sous les outils de vérification de concurrence Miri et Loom. Cela a démontré que l'utilisation appropriée des fossés peut égaler les performances au niveau matériel tout en maintenant les garanties de sécurité de Rust.
Pourquoi un chargement Acquire isolé d'une variable atomique ne garantit-t-il pas la visibilité des écritures non atomiques précédentes dans le fil producteur, même si ce fil a utilisé un stockage Release sur la même variable ?
Un chargement Acquire isolé ne synchronise qu'avec le stockage Release sur cet emplacement atomique spécifique, créant une relation happens-before confinée à cette variable. Cela ne s'étend pas à d'autres emplacements mémoire écrits par le producteur avant le stockage. Pour synchroniser ces écritures, le producteur doit utiliser un fossé Release avant le stockage, ou le consommateur doit utiliser un fossé Acquire après le chargement. Sans ces fossés, le compilateur peut réorganiser les écritures non atomiques après le stockage atomique, et le CPU peut retarder leur visibilité, conduisant à des courses de données sur les données non liées.
Comment le compilateur optimise-t-il les opérations atomiques Relaxed, et pourquoi cela peut-il conduire à des lectures obsolètes contre-intuitives sur x86_64 malgré son fort modèle de mémoire matériel ?
Même sur x86_64, où le matériel fournit un ordre fort, les opérations Relaxed garantissent seulement l'atomicité (pas de lectures/écritures interrompues) mais n'imposent aucune contrainte d'ordre sur les opérations environnantes. Le compilateur est libre de réorganiser les chargements et les stockages Relaxed avec d'autres instructions ou de conserver les valeurs dans des registres, ce qui entraîne qu'un fil observe des valeurs obsolètes par rapport au flux logique du programme. Les candidats confondent souvent la cohérence matérielle avec les garanties du compilateur, oubliant que Relaxed ne fournit aucune protection contre les optimisations du compilateur, nécessitant des sémantiques Acquire/Release pour prévenir la réorganisation.
Qu'est-ce qui distingue un fossé SeqCst d'une combinaison de fossés Acquire et Release, et sous quelle exigence algorithmique spécifique l'ordre total global de SeqCst est-il indispensable ?
Un fossé SeqCst impose un ordre total cohérent global de toutes les opérations SeqCst à travers tous les threads, garantissant que chaque thread observe la même séquence de ces événements. En revanche, les fossés Acquire/Release n'établissent que des synchronisations par paire entre des threads spécifiques et des emplacements mémoire sans consensus global. SeqCst est indispensable pour les algorithmes nécessitant un accord global sur l'ordre des événements, comme l'algorithme d'exclusion mutuelle de Dekker ou les compteurs temporels distribués, où plusieurs threads doivent parvenir indépendamment à la même conclusion sur l'ordre relatif des opérations non liées ; pour des scénarios simples producteur-consommateur, la synchronisation par paire de Acquire/Release est suffisante et plus performante.