Re: should sync builtins be full optimization barriers?

[Paolo Bonzini <bonzini at gnu dot org>]

On 09/12/2011 01:22 AM, Andrew MacLeod wrote:
> > You're right that using lock_test_and_set as an exchange is very wrong
> > because of the compiler barrier semantics, but I think this is
> > entirely a red herring in this case.  The same problem could happen
> > with a fetch_and_add or even a lock_release operation.
>
> My point is that if even once we get the right barriers in place, due to
> its definition as acquire, this testcase could actually still fail, AND
> the optimization is valid...

Ah, sure.

> unless we decide to retroactively make
> all the original sync routine set_cst.

I've certainly seen code using lock_test_and_set to avoid asm for xchg. 
 That would be very much against the documentation with respect to the 
values of the second parameter, and that's also why clang introduced 
__sync_swap.  However, perhaps it makes sense to make lock_test_and_set 
provide sequential consistency.

Probably not much so for lock_release, which is quite clearly a 
store-release.

Paolo