This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Lock elision implementation guidelines
> 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.