teoria - temporizador en java con hilos

¿Por qué no volátil en java 5+ asegura la visibilidad desde otro hilo?

Question

De acuerdo a:

http://www.ibm.com/developerworks/library/j-jtp03304/

Bajo el nuevo modelo de memoria, cuando el hilo A escribe en una variable volátil V, y el hilo B lee desde V, todos los valores de variables que fueron visibles para A en el momento en que se escribió V ahora están garantizados para ser visibles para B

Y muchos lugares en Internet afirman que el siguiente código nunca debería imprimir "error":

public class Test {
volatile static private int a;
static private int b;
public static void main(String [] args) throws Exception {
for (int i = 0; i < 100; i++) {
new Thread() {
@Override
public void run() {
int tt = b; // makes the jvm cache the value of b
while (a==0) {
}
if (b == 0) {
System.out.println("error");
}
}
}.start();
}
b = 1;
a = 1;
}
}

b debe ser 1 para todos los hilos cuando a es 1.

Sin embargo , a veces obtengo un "error" impreso . ¿Cómo es esto posible?

Answer 1

Basado en el extracto de JCiP a continuación, hubiera pensado que su ejemplo nunca debería imprimir "error":

Los efectos de visibilidad de las variables volátiles se extienden más allá del valor de la variable volátil en sí misma. Cuando un hilo A escribe en una variable volátil y posteriormente el hilo B lee esa misma variable, los valores de todas las variables que fueron visibles para A antes de escribir en la variable volátil se vuelven visibles para B después de leer la variable volátil.

Answer 2

En mi opinión, el problema se debe a la falta de sincronización :

AVISO: si b = 1 heppens antes de a = 1, y a es volátil mientras b no lo es, entonces b = 1 realmente se actualiza para todos los hilos solo después de que a = 1 haya terminado (de acuerdo con la lógica del quate).

lo que heppend en su código es que b = 1 se actualizó primero para el proceso principal solamente, solo cuando la asignación volátil finalizó, todos los hilos b se actualizaron. Creo que tal vez las asignaciones de volátiles no funcionan como operaciones atómicas (necesita apuntar lejos y de alguna manera actualizar el resto de las referencias para actuar como volátiles) así que esta sería mi suposición de por qué un hilo lee b = 0 en lugar de b = 1.

Considere este cambio en el código, que muestra mi reclamo:

public class Test {
volatile static private int a;
static private int b;
private static Object lock = new Object();
public static void main(String [] args) throws Exception {
for (int i = 0; i < 100; i++) {
new Thread() {
@Override
public void run() {
int tt = b; // makes the jvm cache the value of b
while (true) {
synchronized (lock ) {
if (a!=0) break;
}
}
if (b == 0) {
System.out.println("error");
}
}
}.start();
}
b = 1;
synchronized (lock ) {
a = 1;
}
}
}

Answer 3

Es posible que desee consultar un hilo de discusión en la lista de correo de interés simultáneo en esta pregunta: cs.oswego.edu/pipermail/concurrency-interest/2012-May/…

Parece que el problema se reproduce más fácilmente con el cliente JVM (-cliente).

Answer 4

Actualizar:

Para cualquier persona interesada, este error se ha solucionado y solucionado para Java 7u6 build b14. Puede ver el informe de errores / arreglos aquí

• Report
• Changeset
• download.java.net/jdk7u6/changes/jdk7u6-b14.html

Respuesta original

Cuando piense en términos de la visibilidad / orden de la memoria, tendrá que pensar en su relación de pase-antes. La pre condición importante para b != 0 es para a == 1 . Si a != 1 entonces b puede ser 0 o 1.

Una vez que un hilo ve a == 1 entonces ese hilo está garantizado para ver b == 1 .

Publicar Java 5, en el ejemplo de OP, una vez que el while(a == 0) rompe, se garantiza que será 1

Editar:

Ejecuté la simulación muchas veces y no vi tu salida.

¿Con qué sistema operativo, versión Java y CPU está probando?

Estoy en Windows 7, Java 1.6_24 (intentando con _31)

Editar 2:

Felicitaciones al OP y a Walter Laan: para mí solo sucedió cuando cambié de Java de 64 bits a Java de 32 bits, en (pero no puede excluirse) a Windows 7 de 64 bits.

Editar 3:

La asignación a tt , o más bien al staticget de b parece tener un impacto significativo (para probar que esto elimina el int tt = b; y siempre debería funcionar).

Parece que la carga de b en tt almacenará el campo localmente, que luego se usará en el coniditonal (la referencia a ese valor no tt ). Entonces, si b == 0 es verdadero, probablemente signifique que la tienda local en tt fue 0 (en este punto es una carrera para asignar 1 a tt local). Esto parece ser cierto solo para 32 Bit Java 1.6 y 7 con el conjunto de clientes.

Comparé los dos conjuntos de salida y la diferencia inmediata fue aquí. (Tenga en cuenta que estos son fragmentos).

Este impreso "error"

 0x021dd753: test %eax,0x180100 ; {poll}
0x021dd759: cmp $0x0,%ecx
0x021dd75c: je 0x021dd748 ;*ifeq
; - Test$1::run@7 (line 13)
0x021dd75e: cmp $0x0,%edx
0x021dd761: jne 0x021dd788 ;*ifne
; - Test$1::run@13 (line 17)
0x021dd767: nop
0x021dd768: jmp 0x021dd7b8 ; {no_reloc}
0x021dd76d: xchg %ax,%ax
0x021dd770: jmp 0x021dd7d2 ; implicit exception: dispatches to 0x021dd7c2
0x021dd775: nop ;*getstatic out
; - Test$1::run@16 (line 18)
0x021dd776: cmp (%ecx),%eax ; implicit exception: dispatches to 0x021dd7dc
0x021dd778: mov $0x39239500,%edx ;*invokevirtual println

Y

Esto no imprimió "error"

0x0226d763: test %eax,0x180100 ; {poll}
0x0226d769: cmp $0x0,%edx
0x0226d76c: je 0x0226d758 ;*ifeq
; - Test$1::run@7 (line 13)
0x0226d76e: mov $0x341b77f8,%edx ; {oop(''Test'')}
0x0226d773: mov 0x154(%edx),%edx ;*getstatic b
; - Test::access$0@0 (line 3)
; - Test$1::run@10 (line 17)
0x0226d779: cmp $0x0,%edx
0x0226d77c: jne 0x0226d7a8 ;*ifne
; - Test$1::run@13 (line 17)
0x0226d782: nopw 0x0(%eax,%eax,1)
0x0226d788: jmp 0x0226d7ed ; {no_reloc}
0x0226d78d: xchg %ax,%ax
0x0226d790: jmp 0x0226d807 ; implicit exception: dispatches to 0x0226d7f7
0x0226d795: nop ;*getstatic out
; - Test$1::run@16 (line 18)
0x0226d796: cmp (%ecx),%eax ; implicit exception: dispatches to 0x0226d811
0x0226d798: mov $0x39239500,%edx ;*invokevirtual println

En este ejemplo, la primera entrada es de una ejecución que imprimió "error" mientras que la segunda fue de una que no lo hizo.

Parece que la ejecución de trabajo se cargó y se le asignó correctamente antes de probarla igual a 0.

 0x0226d76e: mov $0x341b77f8,%edx ; {oop(''Test'')}
0x0226d773: mov 0x154(%edx),%edx ;*getstatic b
; - Test::access$0@0 (line 3)
; - Test$1::run@10 (line 17)
0x0226d779: cmp $0x0,%edx
0x0226d77c: jne 0x0226d7a8 ;*ifne
; - Test$1::run@13 (line 17)

Mientras que la ejecución que imprimió "error" cargó la versión en caché de %edx

 0x021dd75e: cmp $0x0,%edx
0x021dd761: jne 0x021dd788 ;*ifne
; - Test$1::run@13 (line 17)

Para aquellos que tienen más experiencia con el ensamblador, por favor pesen :)

Editar 4

Debería ser mi última edición, ya que el desarrollador de simultaneidad tiene algo que ver, lo hice con y sin int tt = b; asignación un poco más. Descubrí que cuando aumento el máximo de 100 a 1000, parece haber una tasa de error del 100% cuando int tt = b está incluido y un 0% de probabilidad cuando se excluye.