This is the mail archive of the libc-alpha@sourceware.org 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 Wed, 2013-01-16 at 19:52 +0100, Andi Kleen wrote:
> > > 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?
> 
> Currently they do not, but with the trylock change you guys are
> attempting to force on me it'll be needed

No, we could just keep the trylock semantics as specified by POSIX.

> otherwise trylock
> can never elide in a nested lock.

This is not true.  It cannot with your current implementation, but it is
not true in general as you make this sound like.  You have your reasons
to not use xacquire/xrelease, xacquire can't be used when nested in RTM
txns, and SW tracking of which locks a thread acquired is likely to be
too inefficient.  But this doesn't mean this would have to be like this
on all future HW, on all architectures, etc.

> This would only apply to lock types declared by the program, 
> not as declared by environment variables.
> 
> > 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.
> 
> I don't think having a new mutex type for trylock semantics only 
> makes sense. The elision semantics are clearly documented 
> in the manual I wrote.

If you don't want to have a new type, trylock must have the same
semantics as for the respective POSIX locks.  Whether you documented any
changes or not doesn't affect POSIX.

Torvald


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