Re: [PATCH 03/11] Add external interface changes: new lock types for pthread_mutex_t

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2013-06-14 at 15:17 +0200, Andi Kleen wrote:
> > Yes, I'm aware of this.  And that's an unfortunate situation to be in,
> > but I don't see another way to ensure that we still comply with the
> > POSIX requirements -- we can't just ignore those.  Since we had the
> > discussion about the semantics months ago, I haven't seen someone else
> > suggest a different way to solve this
> 
> I don't see this dead lock thing as a requirement (as in likely to
> affect any programs). It's simply a bug.

Read the POSIX requirements, and show us why it's not there:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.html

The only difference between NORMAL and DEFAULT is the relock case.  That
hardly looks like an accidental oversight.

> > I think you should also consider the risk of deviating from the POSIX
> > semantics: If, for example, distributions do not enable elision because
> > they are worried about breaking existing programs, then this will lead
> 
> I'm pretty confident that noone interested in real software
> will worry about their programs not deadlocking, or rather
> taking longer to deadlock (most likely it would deadlock at some point
> if you keep executing it, even with lock elision, as there are always
> a few aborts over time)

I don't see this evidence.  We brought this issue up months ago, it
ended up in the guidelines without further complaints regarding those
guidelines, and I didn't hear anybody from the distribution front, for
example, nor from the Austin Group, say that they wouldn't worry about
breaking this requirement.  Personally, the DEFAULT mutexes' semantics
would be sufficient for me -- but I can't say for sure that that's the
case for everyone.

In any case, whenever we break POSIX requirements, we need a clear
consensus in the project to do that.  I guess the same would be the case
for env vars that lead to this, given the discussion about the env var
rules.  I don't know how people would feel about configure-time options
to change semantics.

> I can clarify it in the documentation though, although I will
> expect it will confuse people more than it will help.

That would be helpful for the case where we have a configure-time option
that breaks the semantics, but it doesn't solve the problem that we do
break the semantics.

Please also have a look at the compromise suggestions I posted as reply
to your introductory email for the patch set.  Even if we can't reach
consensus on how to handle the NORMAL requirements, for example, it
would be useful if we can get those parts in that are not contentious.
I would guess that this should be of interest to you as well.


Torvald