This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 03/10] Add external interface changes: new lock types for pthread_mutex_t
> 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.
email@example.com -- Speaking for myself only.