son - variables atomicas java
¿Qué significa "atómico" en la programación? (5)
En el libro Effective Java, dice:
La especificación de lenguaje garantiza que leer o escribir una variable es atómica a menos que la variable sea de tipo
longodouble[JLS, 17.4.7].
¿Qué significa "atómico" en el contexto de la programación de Java, o la programación en general?
"Operación atómica" significa una operación que parece ser instantánea desde la perspectiva de todos los otros hilos. No necesita preocuparse por una operación parcialmente completa cuando se aplica la garantía.
Acabo de encontrar una operación atómica posterior a no atómica que me ayudó mucho.
"Una operación que actúa en la memoria compartida es atómica si se completa en un solo paso en relación con otros subprocesos.
Cuando se realiza un almacenamiento atómico en una memoria compartida, ningún otro hilo puede observar la modificación a medias.
Cuando se realiza una carga atómica en una variable compartida, lee todo el valor como apareció en un momento en el tiempo ".
Aquí hay un ejemplo, porque un ejemplo es a menudo más claro que una explicación larga. Supongamos que foo es una variable de tipo long . La siguiente operación no es una operación atómica:
foo = 65465498L;
De hecho, la variable se escribe utilizando dos operaciones separadas: una que escribe los primeros 32 bits y una segunda que escribe los últimos 32 bits. Eso significa que otro hilo puede leer el valor de foo y ver el estado intermedio.
Hacer la operación atómica consiste en utilizar mecanismos de sincronización para asegurarse de que la operación se vea, desde cualquier otro hilo, como una operación única, atómica (es decir, no se puede dividir en partes). Eso significa que cualquier otro hilo, una vez que la operación se haga atómica, verá el valor de foo antes de la asignación, o después de la asignación. Pero nunca el valor intermedio.
Una forma simple de hacer esto es hacer que la variable sea volátil :
private volatile long foo;
O para sincronizar cada acceso a la variable:
public synchronized void setFoo(long value) {
this.foo = value;
}
public synchronized long getFoo() {
return this.foo;
}
// no other use of foo outside of these two methods, unless also synchronized
O para reemplazarlo con un AtomicLong :
private AtomicLong foo;
Es algo que "parece que el resto del sistema ocurre de manera instantánea" y cae bajo la categorización de la Linearizability en los procesos informáticos. Para citar más el artículo vinculado:
La atomicidad es una garantía de aislamiento de procesos concurrentes. Además, las operaciones atómicas comúnmente tienen una definición de éxito o fracaso, ya sea que cambian con éxito el estado del sistema o no tienen un efecto aparente.
Así, por ejemplo, en el contexto de un sistema de base de datos, uno puede tener ''confirmaciones atómicas'', lo que significa que puede enviar un conjunto de cambios de actualizaciones a una base de datos relacional y esos cambios se enviarán todos o ninguno de ellos en absoluto. En caso de fallo, de esta manera los datos no se corrompen, y como consecuencia de bloqueos y / o colas, la siguiente operación será una escritura o lectura diferente, pero solo después del hecho. En el contexto de variables y subprocesos esto es muy similar, aplicado a la memoria.
Su cita resalta que este comportamiento no debe ser esperado en todos los casos.
Si tiene varios hilos ejecutando los métodos m1 y m2 en el siguiente código:
class SomeClass {
private int i = 0;
public void m1() { i = 5; }
public int m2() { return i; }
}
Usted tiene la garantía de que cualquier hilo que llame a m2 leerá 0 o 5.
Por otro lado, con este código (donde i es un largo):
class SomeClass {
private long i = 0;
public void m1() { i = 1234567890L; }
public long m2() { return i; }
}
un hilo que llama a m2 podría leer 0, 1234567890L, o algún otro valor aleatorio porque no se garantiza que la instrucción i = 1234567890L sea atómica por long (una JVM podría escribir los primeros 32 bits y los últimos 32 bits en dos operaciones y un hilo podría observarme en el medio).