Re: x86 instructions: atomic vs non-atomic assignment in C

[LIU Hao via Gcc]

在 2026-9-25 12:12, Andrey Tarasevich via Gcc 写道:

My question is: is there a tangible rationale/reason for the difference? I do understand 
that "memory-immediate operand" version of `mov` instruction is not atomic as a 
whole. But if I'm not mistaken, the store operation performed by such a `mov` is still 
perfectly atomic by itself (provided the memory location is aligned correctly). Which 
means that for the above purposes a plain `mov` would still satisfy the requirements of 
atomic behavior. Nevertheless, the code generator opts for a separate load into `eax` 
followed by an atomic `xchg`. Why? Is there a reason to prefer that latter approach? Am I 
missing something about the `mov` version?

It's because the builtin assignment operator writes an `_Atomic` object with 
`memory_order_seq_cst`. Given

   // aligned to avoid false sharing
   _Alignas(64) _Atomic int x = 0;
   _Alignas(64) _Atomic int y = 0;

   void
   thread_X(void)
     {
       // same as `atomic_store_explicit(&x, 1, memory_order_seq_cst)`
       x = 1;
     }

   void
   thread_Y(void)
     {
       // same as `atomic_store_explicit(&y, 1, memory_order_seq_cst)`
       y = 1;
     }




And that's why these stores are implemented with XCHG.


--
Best regards,
LIU Hao

The order of the two stores are indeterminate, but all the other threads must see the same; it is not allowed that thread foo sees `x == 1` and `y == 0` (not updated yet) but thread bar sees `x == 0` and `y == 1`.

OpenPGP_signature.asc
Description: OpenPGP digital signature