[PATCH] Optimized __cxa_guard_{acquire,release,abort} for Linux

[Jason Merrill]

Jakub Jelinek wrote:
> We could do a non-atomic store I guess (provided __cxa_abort is never
> called by mistake when the the var has been initialized already and
> the first byte set), but then we'd need to do an unconditional
> FUTEX_WAKE.  I guess we could use instead __sync_lock_test_and_set
> aka. atimic exchange, to atomically swap in 0 and read previous value
> to see if we need FUTEX_WAKE or not.  The unconditional FUTEX_WAKE
> is IMHO more costly than __sync_lock_test_and_set and conditional
> FUTEX_WAKE.

Good point, I think you're right.  I still don't see why you need the 
loop, however; I don't see any way oldv can != old.  The only thing 
other threads can do is add waiting_bit; once we've established that 
waiting_bit is set what could cause the second compare_and_swap to fail?

Jason