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: Andi Kleen <andi at firstfloor dot org>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: Torvald Riegel <triegel at redhat dot com>, libc-alpha at sourceware dot org, Andi Kleen <ak at linux dot jf dot intel dot com>
- Date: Fri, 14 Jun 2013 16:20:29 +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>
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.