[PATCH 05/11] Disable elision for PTHREAD_MUTEX_NORMAL mutexes
Carlos O'Donell
carlos@redhat.com
Fri Jun 28 05:52:00 GMT 2013
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.
More information about the Libc-alpha
mailing list