tipo - Es una escritura a una barrera de memoria volátil en Java

variable tipo volatile

Question

Recientemente escuché en una charla que una escritura en un volatil desencadena una barrera de memoria para cada variable en la que el hilo ha escrito. ¿Es eso realmente correcto? Desde el JLS, parece que solo la variable en cuestión se elimina, pero no otras. ¿Alguien sabe lo que es realmente correcto? ¿Puede uno señalarme una ubicación concreta en el JLS?

Answer 1

La referencia a variables volátiles y otras variables fue correcta. No me di cuenta de que la transitividad de lo que sucede antes es algo que debe ser implementado por la VM, no algo que se desprenda de la definición. Todavía estoy sorprendido de por qué algo con consecuencias de tan largo alcance no se establece claramente, sino que en realidad es un corolario de alguna definición. Para terminar: supongamos que tienes 4 acciones como esta:

thread1        thread2
a1
a2
                a3
                a4

donde a2 es una escritura en una variable volátil v y a3 es una lectura de la misma variable volátil v. Se sigue de la definición de sucede antes de (hb) que hb (a1, a2) y hb (a3, a4). Además, para volátiles tenemos hb (a2, a3). Ahora se sigue de la transitividad requerida de hb que hb (a1, a3). Por lo tanto, la escritura y lectura posterior de la variable volátil v funciona como una barrera de memoria.

Answer 2

Sí, iniciará una barrera. Puedes leer más here . Hay 4 tipos, LoadLoad LoadStore StoreStore StoreLoad.

En cuanto a tu pregunta

Desde el JLS, parece que solo la variable en cuestión se elimina, pero no otras. ¿Alguien sabe lo que es realmente correcto?

Todas las escrituras que se producen antes de un almacén volátil son visibles por cualquier otro subproceso con el predicado de que los otros subprocesos cargan este nuevo almacén. Sin embargo, las escrituras que ocurren antes de una carga volátil pueden o no ser vistas por otros subprocesos si no cargan el nuevo valor.

Para un ejemplo práctico.

volatile int a =0;
int b = 0;

Thread-1
b = 10;
a = 3;

Thread-2
if(a == 0){
  // b can b 10 or 0
} 
if(a == 3){
   // b is guaranteed to be 10 (according to the JMM)
}