On 18/05/16 17:05, Paolo Bonzini wrote:
>
> 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);
Sorry, I can't figure out why it couldn't...
Kind regards,
Sergey
