Re: [Qemu-devel] [PATCH] atomics: add explicit compiler fence in __atomic memory barriers

[Paolo Bonzini]

On 03/06/2015 14:25, Peter Maydell wrote:
>> > +/* __atomic_thread_fence does not include a compiler barrier; instead,
>> > + * the barrier is part of __atomic_load/__atomic_store's "volatile-like"
>> > + * semantics. If smp_wmb() is a no-op, absence of the barrier means that
>> > + * the compiler is free to reorder stores on each side of the barrier.
>> > + * Add one here, and similarly in smp_rmb() and 
>> > smp_read_barrier_depends().
>> > + */
>> > +#define smp_wmb()   ({ barrier(); 
>> > __atomic_thread_fence(__ATOMIC_RELEASE); barrier(); })
> The comment says "add one" but the patch is adding two.
> An explanation of why you need a barrier on both sides and
> can't manage with just one might be helpful.

Well, the reason is mostly that I wasn't sure if one is enough.

We want to keep the fence in place, and two barriers are firm enough to
block it on both sides.  If the fence is a no-op, "barrier();
barrier();" is the same as a single compiler barrier.

Paolo