This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Lock elision implementation guidelines
On Thu, 2013-02-21 at 15:09 +0100, Andi Kleen wrote:
> > I don't think this is any more difficult than saying "we made sqrt XX%
> > slower to preserve the property that the result is correctly rounded".
>
> More like "we made sqrt XX% slower to deliberately add a bug to it".
>
> Deadlocks are bugs!
This statement needs to be more precise to be correct: Deadlocks that
disallow a program to make progress as intended are bugs that violate
liveness guarantees.
Rich's examples show that there can be ways in which self-deadlocks in
particular do not lead to liveness being violated -- pending the forward
progress guarantees he still wants to investigate.
Second, a violation of liveness is not the same as a violation of
safety. If you want to be super conservative in your program, then the
fail-stop behavior of a deadlock is better than undefined behavior.
Personally, I think that the mutex semantics as defined by C++11 are
sufficient, and they're more friendly towards lock elision too. But
POSIX chose another semantics (and I don't think it was a bad choice at
the time when the choice was made), so we have to deal with it. Bad
luck...
Torvald