Wird flüchtiges Bool für die Thread-Kontrolle als falsch angesehen?

volatile kann werden für solche Zwecke eingesetzt. Jedoch dies ist eine Erweiterung zu standard-C++ -von Microsoft:

Microsoft-Spezifische

Objekte deklariert, die als flüchtige sind (...)

• Ein schreiben zu einem flüchtigen Objekt (flüchtiges schreiben), hat das Release-Semantik; (...)
• Ein Lesen einer volatile-Objekt (flüchtig Lesen) Erwerben Semantik; (...)

Dies ermöglicht, flüchtige Objekte verwendet werden, für die Speicher-sperren und Freigaben in Multithread-Anwendungen.^{(emph. Hinzugefügt)}

Ist, soweit ich das verstanden habe, wenn Sie die Visual C++ - compiler, ein volatile bool ist für die meisten praktischen Zwecke eine atomic<bool>.

Es sollte angemerkt werden, dass neuere VS-Versionen fügen Sie ein /volatile-Schalter , steuert dieses Verhalten, so dass diese nur gilt, wenn /volatile:ms aktiv ist.

InformationsquelleAutor der Antwort Martin Ba

Gibt es drei große problem, das Sie konfrontiert sind, wenn multithreading:

1) Synchronisierung und thread-Sicherheit. Variablen werden gemeinsam von mehreren threads müssen davor geschützt werden, auf die geschrieben wird von mehreren threads auf einmal, und verhindert, dass Lesen während der nicht-atomaren schreibt. Synchronisation von Objekten kann nur durch eine spezielle semaphore/mutex-Objekt, das garantiert atomic von selbst. Das volatile-Schlüsselwort nicht helfen.

2) Instruktion Rohrleitungen. Eine CPU, die Reihenfolge zu ändern, in dem einige Anweisungen, die ausgeführt werden, um code schneller laufen. In einem multi-CPU-Umgebung, wo ein thread ausgeführt wird pro CPU, die CPUs Rohr Anweisungen, ohne zu wissen, dass eine andere CPU im system ist das gleiche zu tun. Schutz gegen Unterricht Rohrleitungen heißt memory-Barrieren. Es ist alles gut erklärt auf Wikipedia. Speicher Barrieren implementiert werden kann, entweder durch dedizierte memory-Barriere-Objekten oder durch das semaphor/mutex-Objekt im system. Ein compiler könnte möglicherweise wählte zum aufrufen einer memory-Barriere in den code, wenn das volatile-Schlüsselwort verwendet wird, aber das wäre eher die Besondere Ausnahme und nicht die Regel. Ich würde nie davon ausgehen, dass das volatile-Schlüsselwort geschafft haben, ohne es verifiziert, die in der compiler-Handbuch.

3) Compiler Unwissenheit von callback-Funktionen. Genauso wie für hardware-interrupts, einige Compiler kann nicht wissen, dass eine callback-Funktion ausgeführt wurde und aktualisiert den Wert in der Mitte des Codes. Können Sie code wie diesen:

//main
x=true;
while(something) 
{   
  if(x==true)   
  {
    do_something();
  }
  else
  {
    do_seomthing_else();
    /* The code may never go here: the compiler doesn't realize that x 
       was changed by the callback. Or worse, the compiler's optimizer 
       could decide to entirely remove this section from the program, as
       it thinks that x could never be false when the program comes here. */
  } 
}

//thread callback function:
void thread (void)
{
  x=false;
}

Beachten Sie, dass dieses problem erscheint nur auf einige Compiler, je nach optimizer-Einstellungen. Dieses problem wird gelöst durch das volatile-Schlüsselwort.

Also die Antwort auf die Frage ist: in einem multi-threaded Programm, das volatile-Schlüsselwort nicht helfen, mit thread-Synchronisation/Sicherheit, tut es wahrscheinlich nicht als memory-Barriere, aber es könnte verhindern, dass gegen gefährliche Annahmen durch den compiler optimizer.

InformationsquelleAutor der Antwort Lundin

Dieser Arbeit wird für Ihren Fall aber zum Schutz eines kritischen Abschnitts dieser Ansatz ist falsch. Wenn es richtig ist, dann könnte man verwenden, eine volatile bool in fast allen Fällen, in denen ein mutex verwendet wird. Der Grund dafür ist, dass eine volatile-variable nicht garantieren Durchsetzung Speicher Barrieren noch alle cache-Kohärenz-Mechanismus. Im Gegenteil, ein mutex hat. In anderen Worten, sobald ein mutex gesperrt ist eine cache-Invalidierung broadcast an alle Kerne, um die Konsistenz zu wahren unter aller Kerne während. Mit volatile dies ist nicht der Fall.
Dennoch, Andrei Alexandrescu vorgeschlagen einen sehr interessanten Ansatz zu verwenden volatile zu erzwingen Synchronisation auf ein gemeinsames Objekt. Und wie Sie sehen werden, er tut es mit einem mutex; volatile wird nur verwendet, um zu verhindern, dass der Zugriff auf das Objekt die Schnittstelle, ohne die Synchronisierung.

InformationsquelleAutor der Antwort PoP