This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 05/11] Disable elision for PTHREAD_MUTEX_NORMAL mutexes
- From: "Carlos O'Donell" <carlos 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: Fri, 28 Jun 2013 01:28:43 -0400
- Subject: Re: [PATCH 05/11] Disable elision for PTHREAD_MUTEX_NORMAL mutexes
- References: <1372098290-29147-1-git-send-email-andi at firstfloor dot org> <1372098290-29147-6-git-send-email-andi at firstfloor dot org>
On 06/24/2013 02:24 PM, Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
>
> There was a lot of discussion about the POSIX statement that
> PTHREAD_MUTEX_NORMAL "shall" deadlock for mutexes that
> get re-acquired by the same thread.
>
> Elided mutexes act like recursive locks and would only deadlock
> sometimes (any time an abort happens, e.g. at program startup
> or when context switches or syscalls happen), but not guaranteed
> every time.
>
> This does not apply to DEFAULT mutexes. But currently in glibc DEFAULT and
> NORMAL is the same number.
>
> The only way NORMAL can be set is through pthread_mutexattr_setkind()
> PTHREAD_MUTEX_INITIALIZER initialized mutexes are default.
>
> So what we do here is:
> - Add a new numeric value for PTHREAD_MUTEX_NORMAL
> - Add a new symbol version for pthread_mutexattr_setkind
> (and its aliases pthread_mutexattr_settype_np and __pthread_mutexattr_settype)
> that disables elision for the new PTHREAD_MUTEX_NORMAL value
> - The compat version for the old symbol version always
> disables elision when a 0 type (old ambigious DEFUALT/NORMAL)
> is passed.
What we actually want to do is avoid the ABI/API changes in the first
patchset. We want this patch to create a new internal-only type for
NORMAL and use that internally to distinguish DEFAULT from NORMAL.
We have already discussed this in the other thread when you posted
this patch as a specific patch.
The new patch to create the internal-only type can be posted
separately from the first patchset if you wish, and can just be
groundwork for your following patches. We can check such a patch
in immediately without any problems.
Cheers,
Carlos.