On 18/05/2016 15:59, Sergey Fedorov wrote:
> 
> But actually (cf include/qemu/atomic.h) we can have:
> 
>     #define atomic_read(ptr)                              \
>         ({                                                \
>         QEMU_BUILD_BUG_ON(sizeof(*ptr) > sizeof(void *)); \
>         typeof(*ptr) _val;                                \
>          __atomic_load(ptr, &_val, __ATOMIC_RELAXED);     \
>         _val;                                             \
>         })
> 
> 
> I can't find anywhere if this __atomic_load() has volatile/compiler
> barrier semantics...

The standard says "you can have data races on atomic loads", that is
very close to compiler barrier semantics but indeed atomics.txt should
be updated to explain the C11 memory model in not-so-formal terms.

For example this:

  atomic_set(&x, 1);
  atomic_set(&y, 1);
  atomic_set(&x, 2);
  atomic_set(&y, 2);

could become

  atomic_set(&x, 2);
  atomic_set(&y, 2);

with C11 atomics but not with volatile.  However this:

  if (atomic_read(&x) != 1) {
    atomic_set(&x, 1);
  }

couldn't become an unconditional

  atomic_set(&x, 1);

Thanks,

Paolo

Reply via email to