Las lecturas de campos volátiles han adquirido semántica . Esto significa que se garantiza que la lectura de memoria de la variable volátil ocurrirá antes de cualquier lectura de memoria siguiente. Impide que el compilador realice el reordenamiento, y si el hardware lo requiere (CPU débilmente ordenada), utilizará una instrucción especial para hacer que el hardware elimine cualquier lectura que ocurra después de la lectura volátil pero que se inició especulativamente antes, o la CPU podría evite que se emitan temprano en primer lugar, evitando que ocurra cualquier carga especulativa entre la emisión de la carga adquirida y su retiro.
Las escrituras de campos volátiles tienen semántica de lanzamiento . Esto significa que se garantiza que cualquier escritura de memoria en la variable volátil se retrasará hasta que todas las escrituras de memoria anteriores sean visibles para otros procesadores.
Considere el siguiente ejemplo:
something.foo = new Thing();
Si fooes una variable miembro en una clase, y otras CPU tienen acceso a la instancia del objeto mencionada something, ¡podrían ver el foocambio de valor antes de que las escrituras de memoria en el Thingconstructor sean visibles globalmente! Esto es lo que significa "memoria débilmente ordenada". Esto podría ocurrir incluso si el compilador tiene todas las tiendas en el constructor antes de la tienda foo. Si fooes volatileentonces, la tienda footendrá semántica de lanzamiento, y el hardware garantiza que todas las escrituras antes de la escritura foosean visibles para otros procesadores antes de permitir fooque ocurra la escritura .
¿Cómo es posible que los escritos foose reordenen tan mal? Si la retención de línea de caché fooestá en el caché, y las tiendas en el constructor perdieron el caché, entonces es posible que la tienda se complete mucho antes de lo que fallan las escrituras en el caché.
La (horrible) arquitectura Itanium de Intel tenía una memoria débilmente ordenada. El procesador utilizado en el XBox 360 original tenía una memoria débilmente ordenada. Muchos procesadores ARM, incluido el muy popular ARMv7-A, tienen poca memoria ordenada.
Los desarrolladores a menudo no ven estas carreras de datos porque cosas como los bloqueos harán una barrera de memoria completa, esencialmente lo mismo que adquirir y liberar semántica al mismo tiempo. No se pueden ejecutar especulativamente cargas dentro del bloqueo antes de que se adquiera el bloqueo, se retrasan hasta que se adquiere el bloqueo. No se pueden retrasar las tiendas a través de una liberación de bloqueo, la instrucción que libera el bloqueo se retrasa hasta que todas las escrituras realizadas dentro del bloqueo sean visibles globalmente.
Un ejemplo más completo es el patrón de "bloqueo de doble verificación". El propósito de este patrón es evitar tener que adquirir siempre un bloqueo para inicializar un objeto de forma diferida.
Enganchado de 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;
}
}
En este ejemplo, las tiendas en el MySingletonconstructor podrían no ser visibles para otros procesadores antes de la tienda mySingleton. Si eso sucede, los otros hilos que miran a mySingleton no adquirirán un bloqueo y no necesariamente recogerán las escrituras al constructor.
volatilenunca evita el almacenamiento en caché. Lo que hace es garantizar el orden en que otros procesadores "ven" escribe. Un lanzamiento de tienda retrasará una tienda hasta que se completen todas las escrituras pendientes y se haya emitido un ciclo de bus que indique a otros procesadores que descarten / reescriban su línea de caché si tienen las líneas relevantes almacenadas en caché. Una adquisición de carga vaciará cualquier lectura especulada, asegurando que no serán valores obsoletos del pasado.