[RFC] Lock elision implementation guidelines

[Andi Kleen]

> That's a good counter example -- I hadn't thought about signal handling.

Any signal will abort of course.

> The same question also applies to program exit: Is a program with a

Program exit will also abort.

> Andi: do you see any reasons why this would be really helpful for
> experimentation (i.e., helpful enough to justify carrying this "hack"
> around in glibc)?

Not sure what hack you mean. I don't have plans to implement deadlocks
deliberately. Iff the standard really requires that I would consider
it a defect in the standard.

> So, while I agree that we want to avoid making people write their own
> lock implementations, I don't see anything wrong with them actually
> doing that in cases where it's beneficial for them and they want to do
> better than the one-size-fits-all automatic tuning.

Note that POSIX pthreads does not export enough primitives for
efficient spinning.  However that's good for lock elision.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.