[RFC] Lock elision implementation guidelines

[Carlos O'Donell]

On 02/21/2013 10:19 AM, Torvald Riegel wrote:
> 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...

Agreed. Having fail-stop behaviour removed is detrimental to writing
robust software.

For C++11 we may be able to provide some non-portable extensions that
allow us to express what we need.

Cheers,
Carlos.