Considere el siguiente código condensado:

/* Compile: gcc -pthread -m32 -ansi x.c */
#include <stdio.h>
#include <inttypes.h>
#include <pthread.h>

static volatile uint64_t v = 0;

void *func (void *x) {
    __sync_add_and_fetch (&v, 1);
    return x;
}

int main (void) {
    pthread_t t;
    pthread_create (&t, NULL, func, NULL);
    pthread_join (t, NULL);
    printf ("v = %"PRIu64"\n", v);
    return 0;
}

Tengo unuint64_t variable que quiero incrementar atómicamente, porque la variable es un contador en un programa multiproceso. Para lograr la atomicidad utilizo GCC'satomic builtins.

Si compilo para un sistema amd64 (-m64), el código ensamblador producido es fácil de entender. Al usar unalock addq, el procesador garantiza que el incremento sea atómico.

 400660:       f0 48 83 05 d7 09 20    lock addq $0x1,0x2009d7(%rip)

Pero el mismo código C produce un código ASM muy complicado en un sistema ia32 (-m32):

804855a:       a1 28 a0 04 08          mov    0x804a028,%eax
804855f:       8b 15 2c a0 04 08       mov    0x804a02c,%edx
8048565:       89 c1                   mov    %eax,%ecx
8048567:       89 d3                   mov    %edx,%ebx
8048569:       83 c1 01                add    $0x1,%ecx
804856c:       83 d3 00                adc    $0x0,%ebx
804856f:       89 ce                   mov    %ecx,%esi
8048571:       89 d9                   mov    %ebx,%ecx
8048573:       89 f3                   mov    %esi,%ebx
8048575:       f0 0f c7 0d 28 a0 04    lock cmpxchg8b 0x804a028
804857c:       08 
804857d:       75 e6                   jne    8048565 <func+0x15>

Esto es lo que no entiendo:

lock cmpxchg8b hac garantiza que la variable modificada solo se escribe si el valor esperado aún reside en la dirección de destino. Se garantiza que la comparación y el intercambio se realizarán atómicamente.Per ¿qué garantiza que la lectura de la variable en 0x804855a y 0x804855f sea atómica?

Probablemente no importa si hubo una "lectura sucia", pero ¿podría alguien describir un @ cortprueb que no hay problema

Más: ¿Por qué el código generado vuelve a saltar a 0x8048565 y no a 0x804855a? Estoy seguro de que esto solo es correcto si otros escritores también incrementan la variable. ¿Es este un requisito implicado para la__sync_add_and_fetch función?