This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 03/10] Add external interface changes: new lock types forpthread_mutex_t
On Sun, Jan 13, 2013 at 04:20:26PM -0500, Carlos O'Donell wrote:
>
> > 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?
Environment variable can enable/disable.
To give the program full control it needs two bits per lock: force enable/disable
so that it can override any environment state.
With the trylock change we would also need to distingush between
auto enabled elision and program force enabled elision (so that force
enables can still do trylock elision, but auto enabled would not).
This would need a third bit.
> >> (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.
You mean the pthreads code? No it won't get any simpler. All the code
paths are still needed. Elision typically needs to do something different
from non elision.
The only advantage of having less types would be that pthread.h has a few
less enums/defines.
> > 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?
Yes that would work. I can look into it it.
-Andi
--
ak@linux.intel.com -- Speaking for myself only