Benötige ich in einer Multi-Thread-C ++-App einen Mutex, um einen einfachen Booleschen zu schützen?

Question

Ich habe eine Multi-Thread-C ++-App, die 3D-Rendering mit der OpenCenegraph-Bibliothek durchführt. Ich plane, die Renderschleife von OSG als separates Thread mit Boost :: Threads zu starten und eine Datenstruktur mit gemeinsamem Zustand in den Thread zu übergeben. Ich versuche, etwas zu schweres Gewicht (wie Mutexes) für die Synchronisation zu vermeiden, da die Renderschleife ziemlich eng sein muss, und OSG selbst versucht es zu vermeiden, jemals ein Verschließen zu haben. Der größte Teil des gemeinsam genutzten Zustands wird vor Beginn des Threads festgelegt und nie geändert. Ich habe einige Daten, die geändert werden müssen, die ich für Doppelpuffer plane. Ich habe jedoch einen einfachen Booleschen, um den Thread zu signalisieren, das Rendering zu suspendieren, und das spätere Wiederaufnahme des Renders und einen weiteren, um ihn zu töten. In beiden Fällen legt der App -Thread den Bool fest und der Render -Thread liest ihn nur. Muss ich den Zugriff auf diese Bools synchronisieren? Soweit ich das beurteilen kann, ist das Schlimmere, was passieren könnte, dass die Render -Schleife für einen zusätzlichen Rahmen fortgesetzt wird, bevor sie suspendiert oder aufhören.

Answer 1

In C ++ 11 und später, die Standards definierte Parallelität aufweist, verwenden Sie std::atomic<bool> für diesen Zweck. Aus http://en.cppreference.com/w/cpp/atomic/atomic:

Wenn ein Thread in ein Atomobjekt schreibt, während ein anderer Thread daraus liest, ist das Verhalten gut definiert (Speichermodell für Details zu Datenrennen).

---

Die folgende alte Antwort war möglicherweise irgendwann in der Vergangenheit mit einigen Compilern und einigen Betriebsumgebungen wahr, sollte sich aber heute nicht verlassen:

Sie haben Recht, in diesem Fall müssen Sie die Bools nicht synchronisieren. Sie sollten sie deklarieren volatile Um sicherzustellen, dass der Compiler sie jedes Mal aus dem Gedächtnis liest, anstatt die vorherige Lektüre in einem Thread zu zwischenstrichen (das ist eine vereinfachte Erklärung, sollte dies jedoch für diesen Zweck tun).

Die folgende Frage enthält weitere Informationen dazu: C ++ - Thread, freigegebene Daten

Answer 2

Warum nicht einfach eine verwenden Verriegelte Variable?

Answer 3

Was C ++ 11 betrifft, und später ist es schließlich threadsbewusst und deutet deutlich an, dass das Ändern eines BOOL (oder einer anderen nicht -atomarischen Variablen) in einem Thread und gleichzeitig in einem anderen Zugriff auf ein undefiniertes Verhalten ist. In Ihrem Fall verwenden std::atomic<bool> Sollte ausreichen, um Ihr Programm korrekt zu machen und Sie vor der Verwendung von Schlösser zu bewahren.
Verwende nicht volatile. Es hat nichts mit Fäden zu tun. Für weitere Diskussionen schauen Sie sich an Kann ich eine BOOL -Variable in einem Thread ohne Mutex lesen?

Answer 4

Ich glaube nicht dich brauchen Ein vollwertiger Mutex hier - obwohl der Render -Thread im Status "Suspended" warten muss, wenn Sie kein Synchronisationsobjekt verwenden, das einen Wartezeit -Primitiv unterstützt.

Sie sollten jedoch die verschiedenen Interlocked Exchange -Primitiven untersuchen (InterlockedExchange unter Windows). Nicht, weil Lese-/Schreibvorgänge aus dem Bool nichtatomar sind, sondern um sicherzustellen, dass es keine seltsamen Verhaltensweisen gibt, die der Compiler-Neuzugriff auf einen einzelnen Thread zugreifen.

Answer 5

Dieser Thread hat etwas mehr Informationen und Diskussionen über Thread-Safety, insbesondere für einfache Datentypen:

Wie kann ich in Windows ein Thread-Safe-Singleton-Muster erstellen?