This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Update on freeze status of glibc 2.18?
- From: Torvald Riegel <triegel at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Ryan Arnold <rsa at us dot ibm dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Mon, 17 Jun 2013 23:18:20 +0200
- Subject: Re: Update on freeze status of glibc 2.18?
- References: <51B65DE4 dot 4010107 at redhat dot com> <20130610231903 dot D9C602C09B at topped-with-meat dot com> <51B66222 dot 1040300 at redhat dot com> <20130614224427 dot 4B2532C077 at topped-with-meat dot com> <51BF3CF8 dot 1010901 at redhat dot com> <1371494971 dot 16968 dot 21574 dot camel at triegel dot csb> <20130617193649 dot 7B5872C08D at topped-with-meat dot com>
On Mon, 2013-06-17 at 12:36 -0700, Roland McGrath wrote:
> > The way I read Roland's comment is that independently of whether things
> > are controlled via a configure switch instead of an env var, they should
> > not diverge from the API or ABI guarantees (and this includes the POSIX
> > guarantees such as the relock case requirements for
> > PTHREAD_MUTEX_NORMAL). Roland, is that correct?
>
> Correct. This also means not introducing new API or ABI features.
Okay, looking at the lock elision case specifically, this would then
mean:
1) Don't use elision for PTHREAD_MUTEX_NORMAL because we can't fulfill
the relock requirements. I suppose giving PTHREAD_MUTEX_DEFAULT a new
value would be okay because that can happen unconditionally, and it
doesn't break existing applications (we of course would need to handle
the new value everywhere).
2) Don't support elision with (nested) trylock because it can't be done
without changing the ABI; it would violate POSIX semantics.
3a) Don't allow the new MUTEX type modifiers (...ELISION_NP
and ...NO_ELISION_NP) at all because they aren't available by default
(Carlos' requirement to not have elision enabled by default) and we
don't want to introduce new API/ABI features? Or ...
3b) Don't allow the new MUTEX type modifiers (...ELISION_NP
and ...NO_ELISION_NP) to change semantics but be available as a
performance hint? They wouldn't break existing code, but would add new
API and ABI bits. Or ...
3c) Do allow the new MUTEX type modifiers (...ELISION_NP
and ...NO_ELISION_NP) to change semantics because they're new bits and
don't break existing code?
4) Don't allow the performance tuning env vars at all because they add
new API? Or is this okay because of our guidelines that explicitly
exclude the tuning env vars from ABI guarantees?
Which of these are true and which aren't? Any other notable
consequences that are missing in the list above?
If 1, 2, 3a and 4 are correct (and we can give PTHREAD_MUTEX_DEFAULT a
new value), then this would mean that a configure switch would enable
elision for most mutexes (assuming most are of DEFAULT type) in freshly
compiled programs.