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 typesfor pthread_mutex_t
On Sun, 2013-01-13 at 13:29 -0800, Andi Kleen wrote:
> 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.
Are you saying that the locks should provide a different semantics
depending on whether elision is automatically enabled or forced per
mutex instance?
This is bound to lead to confusion and is error-prone. It also means
that forcing the elision bit does not just affect performance but also
correctness. Therefore, I think that we should not change trylock
semantics. If we *really* need to, this should be a new mutex type to
make sure that users are aware of the difference, and that this is
different than just cherry-picking elision as enabled with the
process-wide env vars.
Torvald