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

[Torvald Riegel]

On Fri, 2013-06-14 at 16:20 +0200, Andi Kleen wrote:
> On Fri, Jun 14, 2013 at 03:42:19PM +0200, Andi Kleen wrote:
> > 
> > That's what I wrote for the manual:
> 
> I reconsidered this now because it was still misleading.
> If the lock is executed first (so the dynamic links happen) it will
> also deadlock because dynamic linking aborts. During a program's
> startup phase there are typically quite a few aborts due to various
> environmental factors (page faults, page dirty bits etc.)
> 
> So I rewrote it to:
> 
> 
> A program like
> 
> @smallexample
> /* lock is not a recursive lock type */
> pthread_mutex_lock (&lock);
> /* Relock same lock in same thread */
> pthread_mutex_lock (&lock);
> @end smallexample
> 
> will immediately hang on the second lock (dead lock) without elision.
> With elision the deadlock will only happen on an abort, which can happen 
> early or could happen later, but will likely not happen every time.

Why don't you just say that the relock semantics change to undefined
behavior, thus making PTHREAD_MUTEX_NORMAL have semantics equivalent to
PTHREAD_MUTEX_DEFAULT?  That way, you don't have to define new
semantics, and it's easier to remember and grok for users that are
already familiar with the POSIX mutex types.