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

[Andi Kleen <andi at firstfloor dot org>]

> 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)

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

With the trylock change people are asking for a third flag
would be also needed.

> 
> (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.

> 
> (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.

There are two cases however: new type and initializer.

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

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.

Internally it's all the same.

So I can move the pthread_mutex_init to your new call,
but I would prefer to keep the initializers because they
are much more convenient.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.