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

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

On 01/13/2013 03:43 PM, Andi Kleen wrote:
>> For example:
>>
>> (a) Use bit 30 to mark elision requested, like we do for
>>     shared locks (non-private futex).
> 
> I actually already do that (I have two bits, elision/non elision)

So it's not the same :-)

> The lock types are just to specify these additional bits,
> in combination with the existing lock types.

Which I want to avoid because it complicates the API.
 
> With the trylock change people are asking for a third flag
> would be also needed.

Why can't you collapse that to 2 bits? Reserve 30/29 for elision
uses?

>>
>> (b) Continue to use all of the existing mutex types unmodified.
>>     Check the elision enabled bit instead to determine behaviour.
> 
> That's what the code implements.

Sure since all the extra types are effectively the same behaviour,
but without the types I think the code will be more compact and
easier to follow.

>>
>> (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.
> 
> Ok I can move it to such an interface.

Thanks for considering this.

> There are two cases however: new type and initializer.

Yes.
 
> If the initializers are dropped the drawback however is that you
> always need a function call, it'll be impossible to do with initializers.
> It means that people would always need to write a constructor
> for global locks

I'm willing to concede on this point if you also work out
a mechanism that includes the PSHARED value that we currently
use to enable/disable process private futexes.

At present PTHREAD_MUTEX_INITIALIZER can only be used to create
process private mutexes.

You also win by submitting something for PSHARED first, get that
in and then simply add a new flag for elision (see below).

> Ok one way would be to specify new initializers that
> get additional parameters passed as macros , but I doubt that
> will be any easier to read, than just having new initializer.

That might be an interesting solution. I like where you're goin
with this idea.

e.g.
PTHREAD_MUTEX_INIT_NP(lock, PTHREAD_PROCESS_PRIVATE \
                            | PTHREAD_MUTEX_ELIDED);

Seems readable?

Macro always resolves to a constant initializer.

Cheers,
Carlos.