This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 03/11] Add external interface changes: new lock types for pthread_mutex_t
- From: Torvald Riegel <triegel at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: libc-alpha at sourceware dot org, Andi Kleen <ak at linux dot jf dot intel dot com>
- Date: Sat, 15 Jun 2013 16:19:03 +0200
- Subject: Re: [PATCH 03/11] Add external interface changes: new lock types for pthread_mutex_t
- References: <1370969416-8337-1-git-send-email-andi at firstfloor dot org> <1370969416-8337-4-git-send-email-andi at firstfloor dot org> <1371140842 dot 16968 dot 19094 dot camel at triegel dot csb> <20130613211520 dot GP6123 at two dot firstfloor dot org> <1371192753 dot 16968 dot 19724 dot camel at triegel dot csb> <20130614131729 dot GR6123 at two dot firstfloor dot org> <20130614134219 dot GS6123 at two dot firstfloor dot org> <20130614142029 dot GV6123 at two dot firstfloor dot org>
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.