Problems with non-atomic access example on GNU website

Question

On the website of GNU, there is a simple example available that is supposed to demonstrate the problems appearing with non-atomic access. The example contains a small mistake, they have forgotten #include <unistd.h>:

#include <signal.h>
#include <stdio.h>
#include <unistd.h>

struct two_words { int a, b; } memory;

static struct two_words zeros = { 0, 0 }, ones = { 1, 1 };

void handler(int signum)
{
   printf ("%d,%d\n", memory.a, memory.b);
   alarm (1);
}

int main (void)
{
   signal (SIGALRM, handler);
   memory = zeros;
   alarm (1);
   while (1)
     {
    memory = zeros;
    memory = ones;
     }
}

The idea is that the assignment memory = zeros; or the memory = ones; takes multiple cycles and thus the interrupt handler will be able to print "0 1" or "1 0" at some point in time.

However, interestingly for the x86-64 architecture, the assembly code produced by the GCC compiler looks as follows. It appears that the assignment is done within one single cycle by the movq instruction:

    .file   "interrupt_handler.c"
    .text
    .comm   memory,8,8
    .local  zeros
    .comm   zeros,8,8
    .data
    .align 8
    .type   ones, @object
    .size   ones, 8
ones:
    .long   1
    .long   1
    .section    .rodata
.LC0:
    .string "%d,%d\n"
    .text
    .globl  handler
    .type   handler, @function
handler:
.LFB0:
    .cfi_startproc
    pushq   %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register 6
    subq    $16, %rsp
    movl    %edi, -4(%rbp)
    movl    4+memory(%rip), %edx
    movl    memory(%rip), %eax
    movl    %eax, %esi
    leaq    .LC0(%rip), %rdi
    movl    $0, %eax
    call    printf@PLT
    movl    $1, %edi
    call    alarm@PLT
    nop
    leave
    .cfi_def_cfa 7, 8
    ret
    .cfi_endproc
.LFE0:
    .size   handler, .-handler
    .globl  main
    .type   main, @function
main:
.LFB1:
    .cfi_startproc
    pushq   %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register 6
    leaq    handler(%rip), %rsi
    movl    $14, %edi
    call    signal@PLT
    movq    zeros(%rip), %rax
    movq    %rax, memory(%rip)
    movl    $1, %edi
    call    alarm@PLT
.L3:
    movq    zeros(%rip), %rax
    movq    %rax, memory(%rip)
    movq    ones(%rip), %rax
    movq    %rax, memory(%rip)
    jmp .L3
    .cfi_endproc
.LFE1:
    .size   main, .-main
    .ident  "GCC: (Ubuntu 7.3.0-16ubuntu3) 7.3.0"
    .section    .note.GNU-stack,"",@progbits

How is it possible that two separate assignments are done within a single cycle? I would think that the assignment of two different ints has to happen to two different pieces of memory, but somehow it seems over here that they are written to the same place.

This example changes when instead of int, I would use double. In that case, the while loop in assembly becomes:

.L3:
    movq    zeros(%rip), %rax
    movq    8+zeros(%rip), %rdx
    movq    %rax, memory(%rip)
    movq    %rdx, 8+memory(%rip)
    movq    ones(%rip), %rax
    movq    8+ones(%rip), %rdx
    movq    %rax, memory(%rip)
    movq    %rdx, 8+memory(%rip)
    jmp .L3

Answer 1

As it is also pointed out this is an old example. Back in those times, the regular machine had a register width of 32-bit or less. Nowadays, it is very common to have a machine with at least 64-bit register widths. This means that if you have 2 ints of 4 bytes, you have a total of 8 bytes, which is exactly the instruction length of the CPU. Also, you have to notice that the 2 ints are not stored in completely unrelated locations to each other. They can be stored adjacent to each other. This means that the GCC compiler can treat them within one instruction because the 2 ints together fit a register and thus require one 64-bit operation. This is a non-mandatory optimization.

Support for 32-byte SIMD vectors is widespread in x86 CPUs (AVX). Therefore, even with doubles, for certain optimization settings, it is possible optimize and process both doubles in a single instruction. It is possible to try on Godbolt and see that GCC and clang optimize away the non-atomic non-volatile stores inside the loop unless you reduce optimization level to -Og.

However, if you want to be sure that no matter the optimization you still get the described behavior then make it volatile and pad them like struct volatile two_words { int a; _Alignas(64) int b; } memory;