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

[Jakub Jelinek]

On Fri, Jan 04, 2008 at 02:50:30PM -0500, Jason Merrill wrote:
> This looks great, and I think should definitely go into 4.3.  One 
> question: why do you need all the cmpxchg in the abort/unlock functions? 
>  If we're in those functions, we already got the lock, so no other 
> thread should be modifying the guard.  Can't we just do a non-atomic 
> assignment and then FUTEX_WAKE?

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.

	Jakub