Lesevorgänge flüchtiger Felder haben Semantik erlangt . Dies bedeutet, dass garantiert ist, dass der aus der flüchtigen Variablen gelesene Speicher vor allen folgenden Speicherlesevorgängen auftritt. Es hindert den Compiler daran, die Neuordnung durchzuführen, und wenn die Hardware dies erfordert (schwach geordnete CPU), verwendet es eine spezielle Anweisung, um die Hardware dazu zu bringen, alle Lesevorgänge zu leeren, die nach dem flüchtigen Lesevorgang auftreten, aber spekulativ früh gestartet wurden, oder die CPU könnte Verhindern Sie, dass sie vorzeitig ausgegeben werden, indem Sie verhindern, dass zwischen der Ausgabe des Erwerbs der Last und ihrer Stilllegung spekulative Belastungen auftreten.
Schreibvorgänge flüchtiger Felder haben eine Release-Semantik . Dies bedeutet, dass garantiert wird, dass alle Speicherschreibvorgänge in die flüchtige Variable verzögert werden, bis alle vorherigen Speicherschreibvorgänge für andere Prozessoren sichtbar sind.
Betrachten Sie das folgende Beispiel:
something.foo = new Thing();
Wenn fooes sich um eine Mitgliedsvariable in einer Klasse handelt und andere CPUs Zugriff auf die Objektinstanz haben, auf die verwiesen wird something, wird möglicherweise die Wertänderung fooangezeigt, bevor die Speicherschreibvorgänge im ThingKonstruktor global sichtbar sind! Dies ist, was "schwach geordneter Speicher" bedeutet. Dies kann auch dann auftreten, wenn der Compiler alle Speicher im Konstruktor vor dem Speicher hat foo. Wenn dies der Fall fooist, verfügt volatileder Speicher über fooeine Release-Semantik, und die Hardware garantiert, dass alle Schreibvorgänge vor dem Schreibvorgang foofür andere Prozessoren sichtbar sind, bevor der Schreibvorgang ausgeführt werden kann foo.
Wie ist es möglich, dass die Schreibvorgänge fooso schlecht nachbestellt werden? Wenn sich die Cachezeile fooim Cache befindet und die Speicher im Konstruktor den Cache verpasst haben, kann der Speicher möglicherweise viel früher abgeschlossen werden, als die Schreibvorgänge in den Cache fehlschlagen.
Die (schreckliche) Itanium-Architektur von Intel hatte Speicher schwach geordnet. Der in der ursprünglichen XBox 360 verwendete Prozessor hatte einen schwach geordneten Speicher. Viele ARM-Prozessoren, einschließlich des sehr beliebten ARMv7-A, haben einen schwach geordneten Speicher.
Entwickler sehen diese Datenrennen oft nicht, weil Dinge wie Sperren eine vollständige Speicherbarriere bilden, im Wesentlichen dasselbe wie das gleichzeitige Erfassen und Freigeben von Semantik. Es können keine Lasten innerhalb des Schlosses spekulativ ausgeführt werden, bevor das Schloss erworben wird. Sie werden verzögert, bis das Schloss erfasst wird. Während einer Sperrefreigabe können keine Speicher verzögert werden. Die Anweisung, die die Sperre aufhebt, wird verzögert, bis alle in der Sperre vorgenommenen Schreibvorgänge global sichtbar sind.
Ein vollständigeres Beispiel ist das Muster "Double-Checked Locking". Der Zweck dieses Musters besteht darin, zu vermeiden, dass immer eine Sperre erworben werden muss, um ein Objekt verzögert zu initialisieren.
Aus Wikipedia entnommen:
public class MySingleton {
private static object myLock = new object();
private static volatile MySingleton mySingleton = null;
private MySingleton() {
}
public static MySingleton GetInstance() {
if (mySingleton == null) { // 1st check
lock (myLock) {
if (mySingleton == null) { // 2nd (double) check
mySingleton = new MySingleton();
// Write-release semantics are implicitly handled by marking
// mySingleton with 'volatile', which inserts the necessary memory
// barriers between the constructor call and the write to mySingleton.
// The barriers created by the lock are not sufficient because
// the object is made visible before the lock is released.
}
}
}
// The barriers created by the lock are not sufficient because not all threads
// will acquire the lock. A fence for read-acquire semantics is needed between
// the test of mySingleton (above) and the use of its contents. This fence
// is automatically inserted because mySingleton is marked as 'volatile'.
return mySingleton;
}
}
In diesem Beispiel sind die Speicher im MySingletonKonstruktor möglicherweise für andere Prozessoren vor dem Speicher nicht sichtbar mySingleton. In diesem Fall erhalten die anderen Threads, die einen Blick auf mySingleton werfen, keine Sperre und nehmen die Schreibvorgänge an den Konstruktor nicht unbedingt auf.
volatileverhindert niemals das Caching. Es garantiert die Reihenfolge, in der andere Prozessoren "sehen". Eine Speicherfreigabe verzögert einen Speicher, bis alle ausstehenden Schreibvorgänge abgeschlossen sind und ein Buszyklus ausgegeben wurde, der andere Prozessoren auffordert, ihre Cache-Zeile zu verwerfen / zurückzuschreiben, wenn sie zufällig die relevanten Zeilen zwischengespeichert haben. Bei einer Lasterfassung werden alle spekulierten Lesevorgänge gelöscht, um sicherzustellen, dass es sich nicht um veraltete Werte aus der Vergangenheit handelt.