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 types for pthread_mutex_t

> > 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, otherwise trylock
can never elide in a nested lock.

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.

-- -- Speaking for myself only.

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