Ist das 'volatile' Schlüsselwort in C# immer noch fehlerhaft?

Question

Joe Albahari hat eine great series auf Multithreading, das ist ein Muss lesen und sollte auswendig für jeden bekannt sein, der C# Multithreading.

In Teil 4 jedoch erwähnt er die Probleme mit flüchtigem:

Hinweis, dass flüchtige Anwendung nicht daran hindert, eine Schreib gefolgt von einem Lesen aus getauscht werden, und dies kann Rätsel erstellen. Joe Duffy veranschaulicht das Problem gut mit dem folgenden Beispiel: Wenn Test1 und Test2 gleichzeitig auf verschiedenen Threads ausgeführt werden, ist es möglich für a und b beide mit einem Wert von 0 (trotz der Verwendung von flüchtigen auf beide X und y)

mit einem nachgestellten Hinweis, dass die MSDN-Dokumentation falsch ist:

die Dokumentation MSDN besagt, dass die Verwendung des flüchtigen Schlüsselwort stellt sicher, dass der meist up-to-date-Wert in der Gegenwart Feld jederzeit. Das ist falsch, da, wie wir gesehen haben, ein Schreiben gefolgt von einem Lesen neu geordnet werden kann.

Ich habe überprüfte die MSDN documentation, die zuletzt im Jahr 2015 geändert wurde, aber noch aufgeführt:

Das flüchtige Schlüsselwort gibt an, dass ein Feld von mehrere Threads modifiziert werden könnte, die zur gleichen Zeit ausgeführt werden . Felder, die als flüchtig deklariert sind, unterliegen nicht Compiler-Optimierungen, die Zugriff von einem einzelnen Thread annehmen. Dies stellt sicher, dass der aktuellste Wert immer im Feld zu jeder Zeit vorhanden ist.

Im Moment habe ich noch flüchtig vermeiden zugunsten der ausführlicheren Gewinde zu verhindern, veraltete Daten verwenden:

private int foo; 
private object fooLock = new object(); 
public int Foo { 
    get { lock(fooLock) return foo; } 
    set { lock(fooLock) foo = value; } 
} 

Da die Teile über Multithreading im Jahr 2011 geschrieben wurden, ist das Argument heute noch gültig? Sollten Volatilität noch immer zugunsten von Sperren oder vollen Speicherzäunen vermieden werden, um zu verhindern, dass sehr schwer zu erzeugende Fehler auftreten, die, wie erwähnt, sogar vom CPU-Anbieter abhängen, auf dem sie läuft?

Answer 1

Volatile in seiner aktuellen Implementierung ist nicht gebrochen trotz populären Blog-Beiträge, die so etwas behaupten. Es ist jedoch schlecht spezifiziert und die Idee, einen Modifizierer auf einem Feld zu verwenden, um die Speicherordnung zu spezifizieren, ist nicht so toll (vergleichen Sie flüchtig in Java/C# mit der atomaren Spezifikation von C++, die genügend Zeit hatte, aus früheren Fehlern zu lernen). Der MSDN-Artikel auf der anderen Seite wurde eindeutig von jemandem geschrieben, der kein Geschäft über Nebenläufigkeit spricht und völlig falsch ist. Die einzige vernünftige Option ist es, sie vollständig zu ignorieren.

Flüchtige Garantien acquire/release Semantik, wenn das Feld den Zugriff auf und kann nur auf Typen angewendet werden, mit denen Atom liest und schreibt. Nicht mehr und nicht weniger. Dies ist ausreichend, um viele Lock-Free-Algorithmen wie non-blocking hashmaps effizient zu implementieren.

Ein sehr einfaches Beispiel verwendet eine flüchtige Variable, um Daten zu veröffentlichen. Dank der flüchtigen auf x, die Behauptung im folgenden Ausschnitt kann nicht Feuer:

private int a; 
private volatile bool x; 

public void Publish() 
{ 
    a = 1; 
    x = true; 
} 

public void Read() 
{ 
    if (x) 
    { 
     // if we observe x == true, we will always see the preceding write to a 
     Debug.Assert(a == 1); 
    } 
} 

Flüchtige ist nicht einfach zu bedienen und in den meisten Situationen, die Sie viel besser dran mit etwas höheren Level-Konzept zu gehen, aber wenn die Leistung ist wichtig oder Sie implementieren einige Low-Level-Datenstrukturen, volatile kann äußerst nützlich sein.

Answer 2

Wenn ich die MSDN-Dokumentation lese, glaube ich, dass Sie sagen, wenn Sie auf eine Variable flüchtig sehen, müssen Sie sich keine Sorgen über Compiler-Optimierungen machen, da sie die Operationen neu anordnen. Es bedeutet nicht, dass Sie vor Fehlern geschützt sind, die dadurch verursacht werden, dass Ihr eigener Code Operationen in separaten Threads in der falschen Reihenfolge ausführt. (obwohl zugegebenermaßen der Kommentar nicht klar ist.)

Answer 3

volatile ist eine sehr begrenzte Garantie. Dies bedeutet, dass die Variable keinen Compiler-Optimierungen unterliegt, die den Zugriff von einem einzelnen Thread aus annehmen. Das heißt, wenn Sie in eine Variable aus einem Thread schreiben, dann lesen Sie es aus einem anderen Thread, wird der andere Thread definitiv den neuesten Wert haben. Ohne Flüchtigkeit, ein Multiprozessor ohne Flüchtigkeit, kann der Compiler Annahmen über den Singlethread-Zugriff treffen, indem er beispielsweise den Wert in einem Register hält, was verhindert, dass andere Prozessoren auf den neuesten Wert zugreifen können.

Wie das von Ihnen erwähnte Codebeispiel zeigt, schützt es Sie nicht davor, dass Methoden in verschiedenen Blöcken neu angeordnet werden. In der Tat volatile macht jede einzelnen Zugriff auf eine volatile Variable Atom. Es gibt keine Garantien hinsichtlich der Atomizität von Gruppen solcher Zugriffe.

Wenn Sie nur sicherstellen möchten, dass Ihre Immobilie einen aktuellen Einzelwert hat, sollten Sie einfach volatile verwenden können.

Das Problem tritt auf, wenn Sie versuchen, mehrere parallele Vorgänge so auszuführen, als wären sie atomar. Wenn Sie mehrere Operationen als atomare Operationen erzwingen müssen, müssen Sie die gesamte Operation sperren. Betrachten Sie das Beispiel wieder, aber unter Verwendung von Sperren:

class DoLocksReallySaveYouHere 
{ 
    int x, y; 
    object xlock = new object(), ylock = new object(); 

    void Test1()  // Executed on one thread 
    { 
    lock(xlock) {x = 1;} 
    lock(ylock) {int a = y;} 
    ... 
    } 

    void Test2()  // Executed on another thread 
    { 
    lock(ylock) {y = 1;} 
    lock(xlock) {int b = x;} 
    ... 
    } 
} 

Die Sperren verursachen kann einige Synchronisation verursachen, die beidea und b von mit dem Wert verhindern kann 0 (ich habe nicht getestet). Da jedoch sowohl x und y unabhängig gesperrt werden, entweder a oder b kann immer noch nicht-deterministisch mit einem Wert von 0.

So im Fall von Einwickeln der Modifikation einer einzelnen Variablen am Ende, sollen Sie sicher sein, mit volatile, und wäre nicht wirklich sicherer mit lock. Wenn Sie mehrere Operationen atomar ausführen müssen, müssen Sie einen lock um den gesamten atomaren Block herum verwenden, da andernfalls die Zeitplanung immer noch zu nicht-deterministischem Verhalten führt.