Warum sollte ein Bool beim Multithreading in C# volatil werden?

Question

Ich verstehe das Stichwort in C++ ziemlich gut. Aber in C# scheint es eine andere Bedeutung zu haben, mehr im Zusammenhang mit Multi-Threading. Ich dachte, Bool-Operationen seien atomar, und ich dachte, wenn die Operation atomar wäre, hätten Sie keine Bedenken. Was vermisse ich?

https://msdn.microsoft.com/en-us/library/x13ttww7.aspx

Answer 1

Das Schlüsselwort volatile in C# dreht sich alles um Lesen/Schreiben Neuordnung, also ist es etwas ziemlich esoterisch.

http://www.albahari.com/threading/part4.aspx#_Memory_Barriers_and_Volatility

(das halte ich über Einfädeln eines der „Bibeln“ sein) schreibt:

Das Schlüsselwort volatile den Compiler weist einen Belegungs-Zaun auf jedem aus diesem Feld lesen zu erzeugen und einen Freigabefaktor bei jedem Schreiben in dieses Feld.Ein Acquire-Fence verhindert, dass andere Lese-/Schreibvorgänge vor dem Zaun verschoben werden; Ein Freigabezaun verhindert, dass andere Lese-/Schreibvorgänge nach dem Zaun verschoben werden. Diese "Halbzäune" ​​sind schneller als Vollzäune, weil sie der Laufzeit und der Hardware mehr Spielraum für Optimierungen geben.

Es ist etwas ganz unlesbar :-)

Jetzt ... Was es bedeutet nicht:

• Es bedeutet nicht, dass ein Wert wird jetzt/gelesen werden wird geschrieben werden jetzt

es bedeutet einfach, dass, wenn Sie etwas von einem flüchtigen Variable lesen, alles el se, die gelesen/geschrieben wurde, bevor dieser "spezielle" Lesevorgang nach diesem "speziellen" Lesevorgang verschoben wird. Es schafft also eine Barriere. Paradoxerweise garantieren Sie beim Lesen einer volatilen Variablen, dass alle Schreibvorgänge, die Sie mit einer anderen Variablen (flüchtig oder nicht) zum Zeitpunkt des Lesens gemacht haben, ausgeführt werden.

Ein flüchtiges Schreiben ist wahrscheinlich etwas wichtiger und wird zum Teil von der Intel-CPU garantiert, und etwas, das von der ersten Version von Java nicht garantiert wurde: keine Neuordnung des Schreibvorgangs. Das Problem war:

object myrefthatissharedwithotherthreads = new MyClass(5); 

wo

class MyClass 
{ 
    public int Value; 
    MyClass(int value) 
    { 
     Value = value; 
    } 
} 

Nun ..., dass die Expression vorstellen kann sein:

var temp = new MyClass(); 
temp.Value = 5; 
myrefthatissharedwithotherthreads = temp; 

wo temp etwas vom Compiler generiert wird, dass man‘ t sehen.

Wenn die Schreibvorgänge neu angeordnet werden können, könnten Sie haben:

var temp = new MyClass(); 
myrefthatissharedwithotherthreads = temp; 
temp.Value = 5; 

und ein anderer Thread eine teilweise initialisiert sehen konnte MyClass, da der Wert von myrefthatissharedwithotherthreads lesbar ist, bevor die Klasse MyClass Initialisierung beendet ist.

Answer 2

dachte ich Bool Operationen

Sie sind in der Tat Atomatom waren.

und ich dachte, dass, wenn die Operation atomar wäre, Sie keine Probleme haben würden.

Hier haben Sie ein unvollständiges Bild. Stellen Sie sich vor, Sie haben zwei Threads, die auf separaten Kernen mit jeweils eigenen Cache-Layern ausgeführt werden. Thread 1 hat foo in seinem Cache und Thread 2 aktualisiert den Wert foo. Thread # 1 wird die Änderung nicht sehen, es sei denn, foo wird als volatile markiert, eine lock erworben, die Interlocked Klasse verwendet oder explizit Thread.MemoryBarrier() genannt, was dazu führen würde, dass der Wert im Cache ungültig wird. guaranteeing that you read the most up to date value:

Mit dem flüchtigen Modifikator wird sichergestellt, dass ein Thread den aktuellsten Wert eines anderen Threads abruft.

Eric Lippert hat eine great post über Volatilität, wo er erklärt:

Die wahre Semantik von flüchtigen liest und schreibt sind wesentlich komplexer als ich hier skizziert habe; in Tatsache, dass sie nicht wirklich garantieren, dass jeder Prozessor stoppt, was es macht und aktualisiert Caches zu/vom Hauptspeicher. Eher bieten sie schwächere Garantien über , wie Speicherzugriffe vor und nach Lesevorgängen und Schreibvorgänge beobachtet werden können, in Bezug aufeinander geordnet werden.

Edit:

Per @xanatos Kommentar Dieses nicht bedeutet, dass volatile garantiert eine sofortige Lese garantiert er einen Read auf den aktualisierten Wert.