Est-ce que num++ peut être atomique pour 'int num' ?

Question

En général, pour int num , num++ (o ++num ), comme une opération de lecture-modification-écriture, est non atomique . Mais je vois souvent des compilateurs, par exemple CCG et génère le code suivant ( essayez ici ):

void f()
{

  int num = 0;
  num++;
}

f():
        push    rbp
        mov     rbp, rsp
        mov     DWORD PTR [rbp-4], 0
        add     DWORD PTR [rbp-4], 1
        nop
        pop     rbp
        ret

Depuis la ligne 5, qui correspond à num++ est une instruction, peut-on conclure que num++ est atomique dans cette affaire ?

Et si oui, cela veut-il dire que les produits ainsi générés num++ peut être utilisé dans des scénarios concurrents (multithreads) sans risque de course aux données (c'est-à-dire que nous n'avons pas besoin de le fabriquer, par exemple, std::atomic<int> et imposer les coûts associés, puisque c'est de toute façon atomique) ?

UPDATE

Remarquez que cette question est pas si l'incrémentation es atomique (ce n'est pas le cas et c'était et c'est toujours la première ligne de la question). Il s'agit de savoir si elle puede dans des scénarios particuliers, c'est-à-dire si la nature d'une seule instruction peut, dans certains cas, être exploitée pour éviter l'overhead de l'algorithme d'analyse de l'information. lock préfixe. Et, comme le mentionne la réponse acceptée dans la section sur les machines uniprocesseur, ainsi que cette réponse , la conversation dans ses commentaires et d'autres expliquent, il peut (mais pas avec C ou C++).

Answer 1

Sur une machine x86 à un seul cœur, une add sera généralement atomique par rapport aux autres codes du processeur. 1 . Une interruption ne peut pas diviser une instruction unique en deux.

L'exécution hors ordre est nécessaire pour préserver l'illusion d'instructions s'exécutant une par une dans l'ordre au sein d'un même noyau. Ainsi, toute instruction s'exécutant sur le même processeur se produira soit complètement avant, soit complètement après l'ajout.

Les systèmes x86 modernes sont multi-cœurs, le cas particulier des uniprocesseurs ne s'applique donc pas.

Si l'on vise un petit PC embarqué et que l'on ne prévoit pas de transférer le code sur autre chose, la nature atomique de l'instruction "add" pourrait être exploitée. D'un autre côté, les plateformes où les opérations sont intrinsèquement atomiques sont de plus en plus rares.

(Cela ne vous aide pas si vous écrivez en C++, cependant. Les compilateurs n'ont pas l'option d'exiger num++ pour compiler vers un add ou xadd de destination mémoire sans a lock préfixe. Ils peuvent choisir de charger num dans un registre et stocker le résultat de l'incrémentation avec une instruction séparée, et le fera probablement si vous utilisez le résultat).

---

Footnote 1 : Le lock Le préfixe existait même sur le 8086 original parce que les périphériques d'E/S fonctionnent en même temps que le CPU ; les pilotes sur un système à un seul cœur ont besoin de lock add pour incrémenter atomiquement une valeur dans la mémoire du dispositif si le dispositif peut également la modifier, ou par rapport à l'accès DMA.

Answer 2

Même si votre compilateur a toujours émis cette opération comme une opération atomique, accéder à num de tout autre thread simultanément constituerait une course aux données selon les normes C++11 et C++14 et le programme aurait un comportement indéfini.

Mais c'est pire que ça. Premièrement, comme cela a été mentionné, l'instruction générée par le compilateur lors de l'incrémentation d'une variable peut dépendre du niveau d'optimisation. Deuxièmement, le compilateur peut réordonner autre les accès à la mémoire autour ++num si num n'est pas atomique, par exemple

int main()
{
  std::unique_ptr<std::vector<int>> vec;
  int ready = 0;
  std::thread t{[&]
    {
       while (!ready);
       // use "vec" here
    });
  vec.reset(new std::vector<int>());
  ++ready;
  t.join();
}

Même si nous supposons de manière optimiste que ++ready est "atomique", et que le compilateur génère la boucle de vérification selon les besoins (comme je l'ai dit, c'est UB et donc le compilateur est libre de la supprimer, de la remplacer par une boucle infinie, etc.), le compilateur pourrait encore déplacer l'affectation du pointeur, ou pire encore l'initialisation de l'objet vector à un point situé après l'opération d'incrémentation, provoquant le chaos dans le nouveau thread. Dans la pratique, je ne serais pas du tout surpris qu'un compilateur optimisateur supprime l'option ready et la boucle de vérification complètement, car cela n'affecte pas le comportement observable selon les règles du langage (par opposition à vos espoirs privés).

En fait, lors de la conférence Meeting C++ de l'année dernière, j'ai entendu parler de dos les développeurs de compilateurs qu'ils mettent très volontiers en œuvre des optimisations qui font que des programmes multithreads écrits naïvement se comportent mal, tant que les règles du langage le permettent, si une amélioration même mineure des performances est constatée dans des programmes correctement écrits.

Enfin, même si si vous ne vous souciiez pas de la portabilité et que votre compilateur était magiquement gentil, le processeur que vous utilisez est très probablement de type CISC superscalaire et décomposera les instructions en micro-opérations, les réordonnera et/ou les exécutera de manière spéculative, dans une mesure uniquement limitée par des primitives de synchronisation telles que (sur Intel) la fonction LOCK préfixe ou clôtures de mémoire, afin de maximiser les opérations par seconde.

Pour faire court, les responsabilités naturelles de la programmation thread-safe sont les suivantes :

1. Votre devoir est d'écrire du code qui a un comportement bien défini selon les règles du langage (et en particulier le modèle de mémoire standard du langage).
2. Le devoir de votre compilateur est de générer du code machine qui a le même comportement bien défini (observable) sous le modèle de mémoire de l'architecture cible.
3. Le devoir de votre CPU est d'exécuter ce code de sorte que le comportement observé soit compatible avec le modèle de mémoire de sa propre architecture.

Si vous voulez le faire à votre façon, cela peut fonctionner dans certains cas, mais comprenez que la garantie est annulée et que vous serez le seul responsable de tout dommage causé par l'utilisation de ce produit. indésirable résultats. :-)

PS : Exemple correctement rédigé :

int main()
{
  std::unique_ptr<std::vector<int>> vec;
  std::atomic<int> ready{0}; // NOTE the use of the std::atomic template
  std::thread t{[&]
    {
       while (!ready);
       // use "vec" here
    });
  vec.reset(new std::vector<int>());
  ++ready;
  t.join();
}

C'est sûr parce que :

1. Les contrôles de ready ne peuvent pas être éliminés par optimisation selon les règles de la langue.
2. El ++ready se passe avant le chèque qui voit ready comme non nulle, et les autres opérations ne peuvent pas être réorganisées autour de ces opérations. Ceci est dû au fait que ++ready et le contrôle sont séquentiellement cohérent qui est un autre terme décrit dans le modèle de mémoire C++ et qui interdit ce réordonnancement spécifique. Par conséquent, le compilateur ne doit pas réordonner les instructions et doit également indiquer au CPU qu'il ne doit pas, par exemple, reporter l'écriture à vec après l'incrément de ready . Cohérence séquentielle est la garantie la plus forte concernant les atomiques dans la norme de langage. Des garanties moindres (et théoriquement moins chères) sont disponibles, par exemple, via d'autres méthodes de l'option std::atomic<T> mais elles sont réservées aux experts et ne sont pas optimisées par les développeurs de compilateurs, car elles sont rarement utilisées.

Answer 3

À l'époque où les ordinateurs x86 n'avaient qu'une seule unité centrale, l'utilisation d'une seule instruction garantissait que les interruptions ne diviseraient pas la lecture/modification/écriture et que la mémoire ne serait pas utilisée comme tampon DMA également, c'était atomique en fait (et le C++ ne mentionnait pas les threads dans la norme, donc ce point n'était pas abordé).

Lorsqu'il était rare d'avoir un double processeur (par exemple un Pentium Pro à double socket) sur le bureau d'un client, je l'utilisais effectivement pour éviter le préfixe LOCK sur une machine à un seul cœur et améliorer les performances.

Aujourd'hui, cela n'aiderait que contre les multiples threads qui ont tous la même affinité avec le CPU, donc les threads qui vous inquiètent n'entreraient en jeu que par l'expiration de la tranche de temps et l'exécution de l'autre thread sur le même CPU (noyau). Ce n'est pas réaliste.

Avec les processeurs modernes x86/x64, l'instruction unique est décomposée en plusieurs éléments. micro-opérations et de plus, la lecture et l'écriture de la mémoire sont mises en mémoire tampon. Ainsi, différents threads s'exécutant sur des CPU différents ne verront pas seulement cela comme non-atomique, mais pourront voir des résultats incohérents concernant ce qu'ils lisent de la mémoire et ce qu'ils supposent que les autres threads ont lu à ce moment-là : vous devez ajouter clôtures de mémoire pour retrouver un comportement sain.

Answer 4

Non. https://www.youtube.com/watch?v=31g0YE61PLQ (C'est juste un lien vers la scène du "Non" de "The Office")

Êtes-vous d'accord pour dire qu'il s'agit d'un résultat possible pour le programme ?

sortie de l'échantillon :

100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100
100

Si c'est le cas, le compilateur est libre de faire en sorte que l'option uniquement sortie possible pour le programme, de la manière dont le compilateur le souhaite. Par exemple, un main() qui ne fait que sortir 100s.

C'est la règle du "comme si".

Et indépendamment de la sortie, vous pouvez penser à la synchronisation des threads de la même manière - si le thread A fait num++; num--; et le fil B lit num à plusieurs reprises, alors un entrelacement valide possible est que le fil B ne lit jamais entre num++ y num-- . Puisque cet entrelacement est valide, le compilateur est libre de faire en sorte que l'élément uniquement l'entrelacement possible. Et supprimer complètement l'incr/decr.

Il y a quelques implications intéressantes ici :

while (working())
    progress++;  // atomic, global

(par exemple, imaginez qu'un autre fil de discussion mette à jour une barre de progression basée sur progress )

Le compilateur peut-il transformer cela en :

int local = 0;
while (working())
    local++;

progress += local;

probablement que c'est valable. Mais ce n'est probablement pas ce que le programmeur espérait :-(

Le comité travaille toujours sur ce sujet. Actuellement, cela "fonctionne" parce que les compilateurs n'optimisent pas beaucoup les atomiques. Mais cela est en train de changer.

Et même si progress était également volatile, cela serait toujours valable :

int local = 0;
while (working())
    local++;

while (local--)
    progress++;

:-/

Answer 5

Oui, mais...

Atomique n'est pas ce que vous vouliez dire. Vous demandez probablement la mauvaise chose.

L'augmentation est certainement atomique . À moins que le stockage ne soit mal aligné (et puisque vous avez laissé l'alignement au compilateur, il ne l'est pas), il est nécessairement aligné sur une seule ligne de cache. En dehors des instructions spéciales de streaming sans cache, chaque écriture passe par le cache. Des lignes de cache complètes sont lues et écrites de manière atomique, jamais autre chose.
Les données plus petites que la ligne de cache sont, bien sûr, également écrites de manière atomique (puisque la ligne de cache environnante l'est).

Est-il à l'abri des fils ?

Il s'agit d'une question différente, et il y a au moins deux bonnes raisons d'y répondre par la négative. "Non !" .

Tout d'abord, il y a la possibilité qu'un autre cœur ait une copie de cette ligne de cache dans L1 (L2 et le haut sont généralement partagés, mais L1 est normalement par cœur !), et modifie simultanément cette valeur. Bien sûr, cela se produit aussi de manière atomique, mais maintenant vous avez deux valeurs "correctes" (correctement, atomiquement, modifiées) -- laquelle est la vraie valeur correcte maintenant ?
L'unité centrale va s'en sortir d'une manière ou d'une autre, bien sûr. Mais le résultat ne sera peut-être pas celui que vous attendez.

Deuxièmement, il y a l'ordonnancement de la mémoire, ou, en d'autres termes, les garanties "happens-before". La chose la plus importante à propos des instructions atomiques n'est pas tant qu'elles sont atomique . C'est une commande.

Vous avez la possibilité d'appliquer une garantie selon laquelle tout ce qui se passe en mémoire est réalisé dans un certain ordre garanti et bien défini où vous avez une garantie "arrivé avant". Cet ordre peut être aussi "détendu" (lire : pas du tout) ou aussi strict que vous le souhaitez.

Par exemple, vous pouvez définir un pointeur vers un bloc de données (par exemple, les résultats d'un calcul) et ensuite, de manière atomique, vous pouvez définir un pointeur vers un bloc de données (par exemple, les résultats d'un calcul). libérer le drapeau "les données sont prêtes". Maintenant, celui qui acquiert ce drapeau sera amené à penser que le pointeur est valide. Et en effet, il le fera siempre être un pointeur valide, jamais autre chose. C'est parce que l'écriture du pointeur s'est produite avant l'opération atomique.