This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]