On 11/01/2011 04:48 PM, Richard Henderson wrote:
On 11/01/2011 01:20 PM, David Miller wrote:
Unfortunately, this is not true.
Otherwise we could change the 32-bit default code generation to
v9 from v7 under Linux.
For v7, pa-risc, and sh, we originally allowed the test_and_set and
lock_release patterns to do non-obvious things with 0/1 constants.
My proposal is to *not* carry that over to the __atomic patterns.
The PA and SH targets have already switched to use kernel helpers,
and no longer rely on this hack. The only one left is Sparc v7.
C++11 and C1x atomics do have an atomic_flag object which implements
test _and_set and clear on a flag, and the standard requires that these
*are* lock free . I was hoping to avoid introducing new routines just
for that object and using the store and exchange since they are
basically the same thing.
If this is going to be a big issue, then maybe we should reverse my
decision to combine their functionality and add __atomic_test_and_set
and __atomic_clear to the __atomic library stable... Im not fond of
that since its just a subclass of exchange and store...
is it their weirdness on those targets you are concerned with? I could
argue that those weirdnesses are only going to show up on targets which
dont have other support anyway...
hmm. As I make that argument, it also occurs to me how it can break. If
atomic_flag HAS to be lockfree, it possible that there is another object
the same size which is not lock free, and if I try to exchange (1) or
store(0) into that object, the test_and-set or clear routine would be
invoked and in a lock-free way.. which is going to break that object.. sigh.
OK, I think i need to revert my position and introduce
__atomic_test_and_set() and __atomic_clear(). bah. I'll work on that
today.
btw, how did that patch pass __sync_release tests?
expand_builtin_sync_lock_release calls the __atomic_store expander now
with 0... oh, its probably doing a compare_and_swap loop... in any
case, the sync_lock_release expander would have to be put back in place.
Andrew
