Re: [PATCH 05/11] Disable elision for PTHREAD_MUTEX_NORMAL mutexes

["Carlos O'Donell" <carlos at redhat dot com>]

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.