Warum leidet Code, der eine gemeinsam genutzte Variable über Threads hinweg mutiert, anscheinend NICHT unter einer Race-Bedingung?

Ich verwende Cygwin GCC und führe diesen Code aus:

#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;
}

Zusammengestellt mit der Zeile : g++ -Wall -fexceptions -g -std=c++14 -c main.cpp -o main.o.

Es werden 1000 gedruckt, was korrekt ist. Ich habe jedoch eine geringere Anzahl erwartet, da Threads einen zuvor inkrementierten Wert überschreiben. Warum leidet dieser Code nicht unter gegenseitigem Zugriff?

Mein Testgerät hat 4 Kerne und ich habe dem mir bekannten Programm keine Einschränkungen auferlegt.

Das Problem besteht weiterhin, wenn der Inhalt des freigegebenen foodurch etwas Komplexeres ersetzt wird, z

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

foo()ist so kurz, dass jeder Thread wahrscheinlich beendet wird, bevor der nächste überhaupt erzeugt wird. Wenn Sie einen zufälligen Schlaf foo()vor dem hinzufügen u++, sehen Sie möglicherweise, was Sie erwarten.

Es ist wichtig zu verstehen, dass eine Rennbedingung nicht garantiert, dass der Code falsch ausgeführt wird, sondern lediglich, dass er alles kann, da es sich um ein undefiniertes Verhalten handelt. Einschließlich Laufen wie erwartet.

Insbesondere auf X86- und AMD64-Maschinen verursachen die Rennbedingungen in einigen Fällen selten Probleme, da viele der Anweisungen atomar sind und die Kohärenzgarantien sehr hoch sind. Diese Garantien sind bei Multiprozessorsystemen etwas reduziert, bei denen das Sperrpräfix benötigt wird, damit viele Anweisungen atomar sind.

Wenn es sich bei Ihrem Inkrement auf Ihrem Computer um eine atomare Operation handelt, wird diese wahrscheinlich korrekt ausgeführt, obwohl es sich laut Sprachstandard um undefiniertes Verhalten handelt.

Insbesondere erwarte ich in diesem Fall, dass der Code möglicherweise zu einem atomaren Fetch and Add- Befehl (ADD oder XADD in X86-Assembly) kompiliert wird, der in Einzelprozessorsystemen tatsächlich atomar ist. Auf Multiprozessorsystemen ist dies jedoch nicht garantiert atomar und eine Sperre wäre erforderlich, um es so zu machen. Wenn Sie auf einem Multiprozessorsystem arbeiten, wird ein Fenster angezeigt, in dem Threads stören und falsche Ergebnisse erzielen können.

Insbesondere habe ich Ihren Code mithilfe von https://godbolt.org/ zur Assembly foo()kompiliert und Folgendes kompiliert:

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

Dies bedeutet, dass ausschließlich eine Additionsanweisung ausgeführt wird, die für einen einzelnen Prozessor atomar ist (obwohl dies, wie oben erwähnt, für ein Multiprozessorsystem nicht der Fall ist).

Ich denke, es ist nicht so sehr die Sache, wenn Sie vor oder nach dem schlafen u++. Es ist vielmehr so, dass die Operation u++in Code übersetzt wird, der - verglichen mit dem Overhead der aufrufenden Spawning-Threads foo- sehr schnell ausgeführt wird, so dass es unwahrscheinlich ist, dass er abgefangen wird. Wenn Sie jedoch die Operation "verlängern" u++, wird die Rennbedingung viel wahrscheinlicher:

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

Ergebnis: 694

Übrigens: Ich habe es auch versucht

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

und es gab mir meistens 1997, aber manchmal 1995.

Es leidet unter einer Rennbedingung. Setzen Sie usleep(1000);vorher u++;ein foound ich sehe jedes Mal eine andere Ausgabe (<1000).

1. Die wahrscheinliche Antwort darauf, warum sich die Racebedingung für Sie nicht manifestiert hat, obwohl sie existiert, ist, dass sie im Vergleich zu der Zeit, die zum Starten eines Threads benötigt wird, foo()so schnell ist, dass jeder Thread beendet wird, bevor der nächste überhaupt starten kann. Aber...

2. Selbst mit Ihrer Originalversion variiert das Ergebnis je nach System: Ich habe es auf einem (Quad-Core-) Macbook versucht und in zehn Durchläufen dreimal 1000, sechsmal sechsmal und einmal 998 Mal. Das Rennen ist also etwas selten, aber deutlich präsent.

3. Sie haben mit kompiliert '-g', wodurch Fehler verschwinden können. Ich habe Ihren Code neu kompiliert, immer noch unverändert, aber ohne '-g', und das Rennen wurde viel ausgeprägter: Ich habe 1000 einmal, 999 dreimal, 998 zweimal, 997 zweimal, 996 einmal und 992 einmal.

4. Re. Der Vorschlag, einen Schlaf hinzuzufügen - das hilft, aber (a) eine feste Schlafzeit lässt die Threads immer noch durch die Startzeit verzerrt (abhängig von der Timer-Auflösung), und (b) ein zufälliger Schlaf verteilt sie, wenn wir wollen ziehe sie näher zusammen. Stattdessen würde ich sie codieren, um auf ein Startsignal zu warten, damit ich sie alle erstellen kann, bevor ich sie zur Arbeit bringen kann. Mit dieser Version (mit oder ohne '-g') erhalte ich überall Ergebnisse, so niedrig wie 974 und nicht höher als 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;
   }