Le letture dei campi volatili hanno acquisito la semantica . Ciò significa che è garantito che la memoria letta dalla variabile volatile si verificherà prima che venga letta qualsiasi memoria successiva. Impedisce al compilatore di eseguire il riordino e, se l'hardware lo richiede (CPU debolmente ordinata), utilizzerà un'istruzione speciale per fare in modo che l'hardware svuoti tutte le letture che si verificano dopo la lettura volatile ma sono state avviate speculativamente in anticipo, oppure la CPU potrebbe impedire che vengano emessi in anticipo in primo luogo, impedendo che si verifichi qualsiasi carico speculativo tra l'emissione del carico acquisito e il suo ritiro.
Le scritture di campi volatili hanno una semantica di rilascio . Ciò significa che è garantito che eventuali scritture di memoria sulla variabile volatile possano essere ritardate fino a quando tutte le precedenti scritture di memoria sono visibili ad altri processori.
Considera il seguente esempio:
something.foo = new Thing();
Se fooè una variabile membro in una classe e altre CPU hanno accesso all'istanza dell'oggetto a cui fa riferimento something, potrebbero vedere il foocambiamento del valore prima che le scritture di memoria nel Thingcostruttore siano visibili globalmente! Questo è ciò che significa "memoria debolmente ordinata". Ciò potrebbe verificarsi anche se il compilatore ha tutti i negozi nel costruttore prima del negozio foo. In fooquesto caso volatileil negozio fooavrà la semantica di rilascio e l'hardware garantisce che tutte le scritture prima della scrittura foosiano visibili ad altri processori prima di consentire l'esecuzione della scrittura foo.
Come è possibile che le scritture foovengano riordinate così male? Se il mantenimento della riga della cache si footrova nella cache e gli archivi nel costruttore hanno perso la cache, è possibile che l'archivio si completi molto prima delle mancate scritture nella cache.
La (terribile) architettura Itanium di Intel aveva debolmente ordinato memoria. Il processore utilizzato nell'XBox 360 originale aveva una memoria debolmente ordinata. Molti processori ARM, incluso il famosissimo ARMv7-A, hanno una memoria debolmente ordinata.
Gli sviluppatori spesso non vedono queste corse di dati perché cose come i blocchi faranno una barriera di memoria piena, essenzialmente la stessa cosa dell'acquisizione e del rilascio della semantica allo stesso tempo. Nessun carico all'interno del blocco può essere eseguito in modo speculativo prima che il blocco venga acquisito, vengono ritardati fino all'acquisizione del blocco. Nessun archivio può essere ritardato attraverso un rilascio del blocco, l'istruzione che rilascia il blocco viene ritardata fino a quando tutte le scritture eseguite all'interno del blocco sono visibili globalmente.
Un esempio più completo è il modello "Blocco doppio controllo". Lo scopo di questo modello è di evitare di acquisire sempre un lucchetto per inizializzare un oggetto in modo pigro.
Preso da Wikipedia:
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 questo esempio, i negozi nel MySingletoncostruttore potrebbero non essere visibili ad altri processori prima del negozio mySingleton. Se ciò accade, gli altri thread che danno un'occhiata a mySingleton non acquisiranno un blocco e non necessariamente raccoglieranno le scritture per il costruttore.
volatilenon impedisce mai la memorizzazione nella cache. Ciò che fa è garantire l'ordine in cui gli altri processori "vedono" le scritture. Un rilascio di un negozio ritarderà un negozio fino al completamento di tutte le scritture in sospeso e un ciclo di bus è stato emesso dicendo ad altri processori di scartare / riscrivere la loro linea di cache se le cache pertinenti sono memorizzate nella cache. Un'acquisizione di carico annulla tutte le letture speculate, assicurando che non siano valori obsoleti del passato.