Pourquoi le code mutant une variable partagée entre les threads ne souffre-t-il apparemment pas d'une condition de concurrence?

J'utilise Cygwin GCC et j'exécute ce code:

#include <iostream>
#include <thread>
#include <vector>
using namespace std;

unsigned u = 0;

void foo()
{
    u++;
}

int main()
{
    vector<thread> threads;
    for(int i = 0; i < 1000; i++) {
        threads.push_back (thread (foo));
    }
    for (auto& t : threads) t.join();

    cout << u << endl;
    return 0;
}

Compilé avec la ligne: g++ -Wall -fexceptions -g -std=c++14 -c main.cpp -o main.o.

Il imprime 1000, ce qui est correct. Cependant, je m'attendais à un nombre inférieur en raison de l'écrasement des threads sur une valeur précédemment incrémentée. Pourquoi ce code ne souffre-t-il pas d'un accès mutuel?

Ma machine de test a 4 cœurs, et je n'ai mis aucune restriction sur le programme que je connais.

Le problème persiste lors du remplacement du contenu du partagé foopar quelque chose de plus complexe, par exemple

if (u % 3 == 0) {
    u += 4;
} else {
    u -= 1;
}

foo()est si court que chaque thread se termine probablement avant même que le suivant ne soit généré. Si vous ajoutez un sommeil pendant un temps aléatoire foo()avant le u++, vous pouvez commencer à voir ce que vous attendez.

Il est important de comprendre qu'une condition de concurrence critique ne garantit pas que le code fonctionnera de manière incorrecte, mais simplement qu'il pourrait faire n'importe quoi, car il s'agit d'un comportement non défini. Y compris courir comme prévu.

En particulier sur les machines X86 et AMD64, les conditions de course causent rarement des problèmes dans certains cas, car la plupart des instructions sont atomiques et les garanties de cohérence sont très élevées. Ces garanties sont quelque peu réduites sur les systèmes multiprocesseurs où le préfixe de verrouillage est nécessaire pour que de nombreuses instructions soient atomiques.

Si l'incrémentation de votre machine est une opération atomique, cela fonctionnera probablement correctement même si selon la norme du langage, il s'agit d'un comportement non défini.

Plus précisément, je pense que dans ce cas, le code peut être compilé en une instruction atomique Fetch and Add (ADD ou XADD dans l'assemblage X86) qui est en effet atomique dans les systèmes à processeur unique, mais sur les systèmes multiprocesseurs, cela n'est pas garanti comme atomique et verrouillé serait nécessaire pour le faire. Si vous utilisez un système multiprocesseur, il y aura une fenêtre où les threads pourraient interférer et produire des résultats incorrects.

Plus précisément, j'ai compilé votre code en assemblage en utilisant https://godbolt.org/ et foo()compile en:

foo():
        add     DWORD PTR u[rip], 1
        ret

Cela signifie qu'il exécute uniquement une instruction d'ajout qui pour un seul processeur sera atomique (bien que comme mentionné ci-dessus, ce n'est pas le cas pour un système multiprocesseur).

Je pense que ce n'est pas tellement le problème si vous vous endormez avant ou après le u++. C'est plutôt que l'opération se u++traduit par du code qui est - comparé à la surcharge des threads générateurs qui appellent foo- très rapidement exécuté de sorte qu'il est peu probable qu'il soit intercepté. Cependant, si vous "prolongez" l'opération u++, la condition de concurrence deviendra beaucoup plus probable:

void foo()
{
    unsigned i = u;
    for (int s=0;s<10000;s++);
    u = i+1;
}

résultat: 694

BTW: j'ai aussi essayé

if (u % 2) {
    u += 2;
} else {
    u -= 1;
}

et cela m'a donné la plupart du temps 1997, mais parfois 1995.

Il souffre d'une condition de race. Mettre usleep(1000);avant u++;dans fooet je vois une sortie différente (<1000) à chaque fois.

1. La réponse probablement pourquoi la condition de la course n'a pas manifesté pour vous, mais il ne exist, est quefoo() est si rapide, par rapport au temps qu'il faut pour démarrer un fil, que chaque fil se termine avant le prochain pouvez même commencer. Mais...

2. Même avec votre version originale, le résultat varie selon le système: je l'ai essayé à votre guise sur un Macbook (quad-core), et en dix courses, j'ai obtenu 1000 trois fois, 999 six fois et 998 une fois. La course est donc assez rare, mais clairement présente.

3. Vous avez compilé avec '-g', ce qui permet de faire disparaître les bugs. J'ai recompilé votre code, toujours inchangé mais sans le'-g' , et la course est devenue beaucoup plus prononcée: j'ai obtenu 1000 une fois, 999 trois fois, 998 deux fois, 997 deux fois, 996 une fois et 992 une fois.

4. Ré. la suggestion d'ajouter un sommeil - cela aide, mais (a) un temps de sommeil fixe laisse les threads toujours biaisés par l'heure de début (sous réserve de la résolution de la minuterie), et (b) un sommeil aléatoire les étale lorsque ce que nous voulons est de rapprochez-les. Au lieu de cela, je les code pour attendre un signal de départ, afin que je puisse les créer tous avant de les laisser travailler. Avec cette version (avec ou sans '-g'), j'obtiens des résultats partout, aussi bas que 974 et pas plus élevés que 998:

   #include <iostream>
   #include <thread>
   #include <vector>
   using namespace std;
   
   unsigned u = 0;
   bool start = false;
   
   void foo()
   {
       while (!start) {
           std::this_thread::yield();
       }
       u++;
   }
   
   int main()
   {
       vector<thread> threads;
       for(int i = 0; i < 1000; i++) {
           threads.push_back (thread (foo));
       }
       start = true;
       for (auto& t : threads) t.join();
   
       cout << u << endl;
       return 0;
   }