Re: [PATCH 03/10] Add external interface changes: new lock typesfor pthread_mutex_t

[Carlos O'Donell <carlos at systemhalted dot org>]

On 01/10/2013 03:19 PM, Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
> 
> timed and adaptive mutexes have new variants that enable or disable elision.
> This allows programs to set elision in a fine grained matter.
> See the manual for more details.
> 
> recursive/pi/error checking mutexes do not elide.
> 
> Recursive could be implemented at some point, but are not currently.
> 
> 2013-01-10  Andi Kleen  <ak@linux.intel.com>
> 
> 	* pthreadP.h: Add elision flags.
> 	* sysdeps/pthread/pthread.h: Add elision initializers.

I'm not happy about the combinatorial explosion of lock types
with elision (as Torvald also points out). 

Users and developers should not have to learn about new lock
types to specifically ask for elision.

I don't think we should expose elision at the lock type level,
instead it should be a requested property of the lock at 
creation time.

For example:

(a) Use bit 30 to mark elision requested, like we do for
    shared locks (non-private futex).

(b) Continue to use all of the existing mutex types unmodified.
    Check the elision enabled bit instead to determine behaviour.

(c) Add specific pthread_mutexattr_*_np() functions to enable
    or disable lock elision with the attribute used to create
    the mutex. Add a new pthread's section in the manual to
    describe these as "reqeust that lock elision be used if
    available" etc. etc.

    I suggest creating a generic interface:
    pthread_mutexattr_setparam_np(int parameter, int value);
    pthread_mutexattr_getparam_np(int parameter, int value);

    Where paramter is one of:
    PTHREAD_MUTEX_ELISION (your new bit)
    PTHREAD_MUTEX_SHARED (the existing bit 31 for pshared)

    Where 0 is disabled, and 1 is enabled.

Wouldn't this be much cleaner than adding new a pile of types?

I'm pretty sure all of the other locks with types have a value
that can be used as a bit-field to add parameters.

We've got a lot of bits available, and I don't see many uses
of the bits.

Comments?

Cheers,
Carlos.