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 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.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.