[RFC] Lock elision implementation guidelines

[Torvald Riegel]

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