¿Qué significa "atómico" en la programación?

En el libro de Effective Java, dice:

La especificación del lenguaje garantiza que leer o escribir una variable es atómica a menos que la variable sea de tipo longo double[JLS, 17.4.7].

¿Qué significa "atómico" en el contexto de la programación Java, o la programación en general?

Aquí hay un ejemplo, porque un ejemplo a menudo es más claro que una explicación larga. Supongamos que fooes 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 otra que escribe los últimos 32 bits. Eso significa que otro hilo podría leer el valor de fooy ver el estado intermedio.

Hacer que la operación sea 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 dividible en partes). Eso significa que cualquier otro subproceso, una vez que la operación se vuelva atómica, verá el valor fooantes o después de la asignación. Pero nunca el valor intermedio.

Una manera 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;

"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.

Es algo que "parece que el resto del sistema ocurre instantáneamente" y se clasifica en la categorización de linealización en los procesos informáticos. Para citar aún más ese artículo vinculado:

La atomicidad es una garantía de aislamiento de los procesos concurrentes. Además, las operaciones atómicas suelen tener una definición de éxito o fracaso: cambian con éxito el estado del sistema o no tienen ningún efecto aparente.

Entonces, por ejemplo, en el contexto de un sistema de base de datos, uno puede tener 'compromisos atómicos', 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 falla, 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 destaca que este comportamiento no tiene que ser esperado en todos los casos.

Acabo de encontrar una publicación de Operaciones atómicas frente a operaciones no atómicas que me fue muy útil.

"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 subproceso puede observar la modificación a medio completar.

Cuando se realiza una carga atómica en una variable compartida, lee el valor completo tal como apareció en un solo momento en el tiempo ".

Si tiene varios subprocesos 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; }
}

tiene la garantía de que cualquier llamada de hilo m2leerá 0 o 5.

Por otro lado, con este código (donde ies largo):

class SomeClass {
    private long i = 0;

    public void m1() { i = 1234567890L; }
    public long m2() { return i; }
}

una llamada de subproceso m2podría leer 0, 1234567890L o algún otro valor aleatorio porque i = 1234567890Lno se garantiza que la declaración sea ​​atómica para a long(una JVM podría escribir los primeros 32 bits y los últimos 32 bits en dos operaciones y un subproceso podría observar ien el medio) .

En Java, la lectura y escritura de campos de todo tipo, excepto long y double, se produce atómicamente, y si el campo se declara con el modificador volátil, incluso long y double se leen y escriben atómicamente. Es decir, obtenemos el 100% de lo que estaba allí o de lo que sucedió allí, ni puede haber ningún resultado intermedio en las variables.