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
