Re: [v3] atomics

[Benjamin Kosnik <bkoz at redhat dot com>]

> What I mean is that if you implement an atomic operation with
> (spin)lock acquire/release, as you've done:
> 
> atomic_op( x )
>     acquire lock for x
>     read or modify x
>     release lock for x
> 
> this atomic operation has sequentially consistent semantics. This
> means that it already implements the "heaviest" constraint,
> memory_order_seq_cst, which is a superset of all the others.

Got it. 
 
> There is no need to insert additional __sync_synchronize calls inside
> the "acquire lock" and "release lock" parts.
> 
> Hans Boehm has a paper with a formal proof that code that uses mutex 
> lock/unlock for synchronization is sequentially consistent:
> 
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2392.html

Thanks for the reference. When config/build damage settles down I'll
take a look at this.

> As an aside, I'd have expected the implementation to use the __sync 
> primitives directly instead of spinlock emulation?

That's certainly the long-term plan. 

-benjamin