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