Multithreading-Programm bleibt im optimierten Modus hängen, läuft aber normal in -O0

Ich habe ein einfaches Multithreading-Programm wie folgt geschrieben:

static bool finished = false;

int func()
{
    size_t i = 0;
    while (!finished)
        ++i;
    return i;
}

int main()
{
    auto result=std::async(std::launch::async, func);
    std::this_thread::sleep_for(std::chrono::seconds(1));
    finished=true;
    std::cout<<"result ="<<result.get();
    std::cout<<"\nmain thread id="<<std::this_thread::get_id()<<std::endl;
}

Es verhält sich normalerweise im Debug-Modus in Visual Studio oder -O0in gc c und druckt das Ergebnis nach 1Sekunden aus. Aber es blieb hängen und druckt nichts im Release- Modus oder -O1 -O2 -O3.

Zwei Threads, die auf eine nicht atomare, nicht geschützte Variable zugreifen, sind UB. Dies betrifft finished. Sie könnten einen finishedTyp std::atomic<bool>eingeben, um dies zu beheben.

Mein Fix:

#include <iostream>
#include <future>
#include <atomic>

static std::atomic<bool> finished = false;

int func()
{
    size_t i = 0;
    while (!finished)
        ++i;
    return i;
}

int main()
{
    auto result=std::async(std::launch::async, func);
    std::this_thread::sleep_for(std::chrono::seconds(1));
    finished=true;
    std::cout<<"result ="<<result.get();
    std::cout<<"\nmain thread id="<<std::this_thread::get_id()<<std::endl;
}

Ausgabe:

result =1023045342
main thread id=140147660588864

Live-Demo auf coliru

Jemand könnte denken: 'Es ist ein bool- wahrscheinlich ein bisschen. Wie kann das nicht atomar sein? ' (Ich habe es getan, als ich selbst mit Multithreading angefangen habe.)

Beachten Sie jedoch, dass das Nicht-Zerreißen nicht das einzige ist, was std::atomic was Sie erhalten. Außerdem wird der gleichzeitige Lese- und Schreibzugriff von mehreren Threads genau definiert, sodass der Compiler nicht davon ausgehen kann, dass beim erneuten Lesen der Variablen immer derselbe Wert angezeigt wird.

Das boolErstellen eines unbewachten, nicht atomaren Geräts kann zusätzliche Probleme verursachen:

• Der Compiler kann entscheiden, die Variable in ein Register oder sogar mehrere CSE-Zugriffe in einen zu optimieren und eine Last aus einer Schleife zu heben.
• Die Variable kann für einen CPU-Kern zwischengespeichert werden. (Im wirklichen Leben haben CPUs kohärente Caches . Dies ist kein wirkliches Problem, aber der C ++ - Standard ist locker genug, um hypothetische C ++ - Implementierungen auf nicht kohärentem gemeinsam genutztem Speicher abzudecken, wo atomic<bool>mit memory_order_relaxedSpeichern / Laden funktionieren würde, aber wovolatile jedoch nicht. Verwenden volatil dafür wäre UB, obwohl es in der Praxis auf echten C ++ - Implementierungen funktioniert.)

Um dies zu verhindern, muss der Compiler ausdrücklich angewiesen werden, dies nicht zu tun.

Ich bin ein wenig überrascht über die sich entwickelnde Diskussion über die mögliche Beziehung volatilezu diesem Thema. Daher möchte ich meine zwei Cent ausgeben:

• Ist flüchtig nützlich bei Threads
• Wer hat Angst vor einem großen, schlechten Optimierungs-Compiler? .

Scheffs Antwort beschreibt, wie Sie Ihren Code reparieren können. Ich dachte, ich würde ein paar Informationen darüber hinzufügen, was in diesem Fall tatsächlich passiert.

Ich habe Ihren Code bei Godbolt mit Optimierungsstufe 1 ( -O1) kompiliert . Ihre Funktion kompiliert wie folgt:

func():
  cmp BYTE PTR finished[rip], 0
  jne .L4
.L5:
  jmp .L5
.L4:
  mov eax, 0
  ret

Also, was passiert hier? Zuerst haben wir einen Vergleich: cmp BYTE PTR finished[rip], 0- Dies prüft, ob finishedfalsch ist oder nicht.

Wenn es nicht falsch ist (auch bekannt als wahr), sollten wir die Schleife beim ersten Lauf verlassen. Dies erreicht durchjne .L4 die j UMPS wenn n ot e Qual zu Label .L4wobei der Wert von i( 0) für eine spätere Verwendung in einem Register gespeichert wird , und die Funktion kehrt zurück.

Wenn es jedoch falsch ist, gehen wir zu

.L5:
  jmp .L5

Dies ist ein bedingungsloser Sprung zum Beschriften, .L5der zufällig der Sprungbefehl selbst ist.

Mit anderen Worten, der Thread wird in eine Endlos-Besetzt-Schleife gebracht.

Warum ist das passiert?

Für den Optimierer liegen Threads außerhalb seines Zuständigkeitsbereichs. Es wird davon ausgegangen, dass andere Threads nicht gleichzeitig Variablen lesen oder schreiben (da dies ein Datenrassen-UB wäre). Sie müssen ihm mitteilen, dass die Zugriffe nicht optimiert werden können. Hier kommt Scheffs Antwort ins Spiel. Ich werde mich nicht die Mühe machen, ihn zu wiederholen.

Da dem Optimierer nicht mitgeteilt wird, dass sich die finishedVariable möglicherweise während der Ausführung der Funktion ändern kann, sieht er, finisheddass sie von der Funktion selbst nicht geändert wird, und geht davon aus, dass sie konstant ist.

Der optimierte Code stellt die beiden Codepfade bereit, die sich aus der Eingabe der Funktion mit einem konstanten Bool-Wert ergeben. Entweder wird die Schleife unendlich ausgeführt, oder die Schleife wird nie ausgeführt.

beim -O0Compiler (wie erwartet) wird der Schleifenkörper und Vergleich nicht weg optimiert:

func():
  push rbp
  mov rbp, rsp
  mov QWORD PTR [rbp-8], 0
.L148:
  movzx eax, BYTE PTR finished[rip]
  test al, al
  jne .L147
  add QWORD PTR [rbp-8], 1
  jmp .L148
.L147:
  mov rax, QWORD PTR [rbp-8]
  pop rbp
  ret

Daher funktioniert die Funktion, wenn sie nicht optimiert ist, ist der Mangel an Atomizität hier normalerweise kein Problem, da der Code und der Datentyp einfach sind. Wahrscheinlich ist das Schlimmste, auf das wir hier stoßen könnten, ein Wert, der ium eins von dem abweicht, was er sein sollte.

Ein komplexeres System mit Datenstrukturen führt mit größerer Wahrscheinlichkeit zu beschädigten Daten oder einer fehlerhaften Ausführung.

Der Vollständigkeit halber in der Lernkurve; Sie sollten die Verwendung globaler Variablen vermeiden. Sie haben gute Arbeit geleistet, indem Sie es statisch gemacht haben, sodass es lokal für die Übersetzungseinheit ist.

Hier ist ein Beispiel:

class ST {
public:
    int func()
    {
        size_t i = 0;
        while (!finished)
            ++i;
        return i;
    }
    void setFinished(bool val)
    {
        finished = val;
    }
private:
    std::atomic<bool> finished = false;
};

int main()
{
    ST st;
    auto result=std::async(std::launch::async, &ST::func, std::ref(st));
    std::this_thread::sleep_for(std::chrono::seconds(1));
    st.setFinished(true);
    std::cout<<"result ="<<result.get();
    std::cout<<"\nmain thread id="<<std::this_thread::get_id()<<std::endl;
}

Lebe auf Zauberstabbox