Soy consciente del siguiente escenario: (formato extraño, lo sé)
private final AtomicBoolean aBoolean = new AtomicBoolean(true); public void doSomething() { if ( aBoolean.get() // line A && // line B aBoolean.compareAndSet(true, false) // line C ) { System.out.println("Was true!") } } Si el subproceso #1 y el subproceso #2 ingresan doSomething() exactamente al mismo tiempo, esto sucederá:
El subproceso #1 y el subproceso #2 leerán aBoolean.get() como == "verdadero" simultáneamente.
Ambos ejecutarán el operador "&&".
La instrucción CMPXCHG se activa para ambos subprocesos simultáneamente:
3.1 El prefijo LOCK se usa de forma nativa
3.2 El hilo n.º 1 o n.º 2 llega primero y gana la carrera.
3.3 Comparaciones de subprocesos ganadores (¿es aBoolean == verdadero?) Esto devolverá "verdadero", por lo tanto, aBoolean se establecerá en "falso".
3.4 aBoolean ahora es falso.
3.5 Perder comparaciones de subprocesos (¿es aBoolean == verdadero?) Esto devolverá "falso", por lo tanto, provocará un cortocircuito en cualquier otra operación.
el hilo ganador imprimirá "¡Era cierto!".
Bajo la perspectiva del hilo "perdedor", el primer aBoolean.get() en la "línea A" fue... digamos... una "mentira".
Ahora, bajo el supuesto de que las ejecuciones pueden ocurrir entre operadores, como sucedió en el ejemplo anterior, agreguemos un segundo método para un segundo escenario:
public void unluckySet() { aBoolean.set(false); } Digamos que el hilo n.º 3 llega y ejecuta unluckySet() precisamente en el momento exacto en que nuestro "hilo ganador" llegó a la "línea B", donde se está ejecutando "&&".
Si el hilo ganador llegó tan lejos como para llegar a la "línea B", significa que llegó a la "línea A" con un valor booleano "verdadero".
Mis preguntas son:
¿CMPXCHG leerá el valor actualizado correctamente como "falso"?, lo que significa que el .set() también está retenido por el mismo bloqueo que el compareAndSet() .
En concurrencia y entre hilos:
¿Los operadores ("&&", "||", "==", "=", tal vez incluso "return;"??) ocurren en cualquier nanosegundo, O están intercalados con ejecuciones (";") para que ambos END de forma intercalada, evitando posibles colisiones?
El modelo de memoria de Java es de consistencia secuencial en ausencia de carreras de datos (que su programa no tiene). Esto es muy fuerte; dice que todas las lecturas y escrituras en su programa forman un orden total, que es consistente con el orden del programa. Entonces, puede imaginar que las lecturas y escrituras de diferentes subprocesos simplemente se intercalan o mezclan, de alguna manera, sin cambiar el orden relativo de las acciones realizadas desde el mismo subproceso entre sí.
Pero para este propósito, cada acción es un elemento separado en este orden. Entonces, solo por el mero hecho de que aBoolean.get() y aBoolean.compareAndSet() son dos acciones y no una sola acción, es posible que cualquier número de otras acciones de otros subprocesos tenga lugar entre ellas.
No importa si esas acciones son parte de una declaración única o de declaraciones diferentes; o en qué tipo de expresión aparecen; o qué operadores (si los hay) hay entre ellos; o qué cálculos puede o no estar haciendo el subproceso a su alrededor. No hay forma de que dos acciones puedan estar "tan juntas" que nada más pueda suceder en el medio, salvo reemplazarlas por una sola acción definida como atómica por el lenguaje.
En el nivel de la máquina, una forma muy sencilla de que esto suceda es que, dado que aBoolean.get() y aBoolean.compareAndSet() son casi con certeza dos instrucciones de máquina diferentes, puede llegar una interrupción entre ellas. Esta interrupción podría causar que el subproceso se retrase por cualquier cantidad de tiempo, durante el cual otros subprocesos podrían hacer lo que deseen. Por lo tanto, es muy posible que los subprocesos n.° 1 y n.° 2 se interrumpan entre get() y compareAndSet() , y que el subproceso n.° 3 ejecute su set mientras tanto.
Precaución: Razonar sobre cómo podría funcionar una máquina en particular a menudo es útil para comprender por qué es posible un comportamiento no deseado, como en el párrafo anterior. Pero no es un sustituto del razonamiento sobre el modelo de memoria formal, y no debe usarse para tratar de argumentar que un programa debe tener el comportamiento deseado. Incluso si una máquina en particular que tiene en mente haría lo correcto para su código, o si no puede pensar en una forma en que una máquina plausible fallaría, eso no prueba que su programa sea correcto.
Entonces, tratar de decir "oh, la máquina hará un lock cmpxchg y así bla, bla, bla y todo funcionará" no es inteligente; alguna otra máquina en la que no haya pensado podría funcionar de una manera totalmente diferente, que todavía cumple con el modelo de memoria abstracto de Java pero que, por lo demás, viola sus expectativas basadas en x86. De hecho, x86 es un ejemplo particularmente pobre de esto: por razones históricas, proporciona un conjunto bastante sólido de garantías de ordenamiento de memoria a nivel de instrucción que muchas otras arquitecturas "ordenadas débilmente" no lo hacen, por lo que puede haber muchas cosas que Java abstractamente permite pero que x86 en la práctica no funcionará.