Cette page est fausse . Il semble prétendre que les opérations atomiques sans verrou sont privilégiées sur les ISA en général, mais ce n'est pas le cas. Je n'ai jamais entendu parler d'un ISA où le test-and-set atomique ou toute autre opération sans verrou nécessitait le mode noyau.
Si c'était le cas, il faudrait Opérations de lecture-modification-écriture atomiques sans verrou C++11 pour compiler les appels système, mais ils ne le font pas sur x86, ARM, AArch64, MIPS, PowerPC, ou tout autre CPU normal. (essayez-le sur https://godbolt.org/ ).
Cela rendrait également impossible le verrouillage "léger" (qui tente de prendre le verrou sans appel système). ( http://preshing.com/20111124/always-use-a-lightweight-mutex/ )
Les ISA normales permettent à l'espace utilisateur d'effectuer des opérations RMW atomiques, sur la mémoire partagée entre les threads ou même entre des processus séparés. Je ne connais pas de mécanisme permettant de désactiver le RMW atomique pour l'espace utilisateur sur x86. Même si une telle chose existe sur n'importe quel ISA, ce n'est pas le mode de fonctionnement normal.
Les accès en lecture seule ou en écriture seule sont en général naturellement atomiques sur des emplacements alignés sur tous les ISA, jusqu'à une certaine largeur ( Pourquoi l'affectation d'un nombre entier sur une variable alignée naturellement est atomique sur x86 ? ), mais le RMW atomique a besoin d'un support matériel.
Sur x86, le TAS est lock bts qui n'est pas privilégiée. ( Documentation pour le lock préfixe ). x86 a un grand site sélection d'autres opérations atomiques, comme lock add [mem], reg/immediate , lock cmpxchg [mem], reg et même lock xadd [mem], reg qui met en œuvre fetch_add lorsque la valeur de retour est nécessaire. ( Est-ce que num++ peut être atomique pour 'int num' ? )
La plupart des RISC ont LL/SC, y compris ARM, MIPS et PowerPC, ainsi que tous les anciens ISA RISC qui ne sont plus courants.
futex(2) est un appel système. Si vous l'appelez, tout ce qu'il fait est en mode noyau.
C'est le mécanisme de repli utilisé par les verrouillages légers au cas où il y a es qui permet de dormir et de se réveiller avec l'aide du système d'exploitation. Ce n'est donc pas futex qui fait quoi que ce soit en espace utilisateur, mais plutôt des implémentations de verrouillage construites autour de futex peut éviter de faire des appels système dans le cas non intentionnel ou de faible contenance.
(par exemple, tourner dans l'espace utilisateur plusieurs fois au cas où le verrou deviendrait disponible).
C'est ce que le futex(7) est décrite dans la page de manuel. Mais je trouve un peu bizarre d'appeler cela une "opération futex" si vous ne faites pas réellement l'appel système. Je suppose qu'il s'agit d'une opération sur la mémoire que le code du noyau pourrait consulter pour le compte d'autres threads en attente, donc la sémantique nécessaire pour modifier les emplacements mémoire dans le code de l'espace utilisateur dépend de futex .
