Re: Update on freeze status of glibc 2.18?

[Torvald Riegel <triegel at redhat dot com>]

On Wed, 2013-06-19 at 15:42 -0700, Roland McGrath wrote:
> > 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).
> 
> If you change the value of PTHREAD_MUTEX_DEFAULT to a new value that
> old libraries don't support, then you need to use a new symbol version
> for pthread_mutexattr_settype.

D'oh, forgot about that.  I suppose that means that because we want to
use the new PTHREAD_MUTEX_DEFAULT value in the initializers, we need a
new symbol version for every function that takes a pthread_mutex_t as
parameter (and could be called with a default-initialized mutex)?

> > 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?
> 
> My strongest requirement is that we not have a configure switch that
> changes what ABI is supported by the shared libraries built.  That's
> just begging for fragmentation and confusion.

Okay.  It would be good to know soon whether that is the consensus in
the project or not, because it affects the HLE patch set significantly.

> So if there are any ABI
> additions, they would have to be unconditional ones, with the
> configure switch affecting only the implementation details and
> performance characteristics, not the semantic guarantees of the ABI.
> Note I say "semantic guarantees", not "semantics".  For example, there
> might be a new type whose semantics are "trylock might lie" (or
> whatever it is), in which case it's OK if the actual behavior of
> trylock differs observably between the --disable-foo and --enable-foo
> builds as long as both are within the range of behaviors the new ABI
> says it might have.
> 
> That said, I am pretty skeptical about adding any API/ABI features at
> all when their only meaning is for non-default code that is not really
> ready for prime time.  Whatever ABI features we introduce, we'll be
> stuck with forever, even if they turn out to be useless or not the
> ideal fit for the implementation we eventually wind up with.

I also see this risk.  That is one of the reasons why I think that any
elision bits in the type should be performance hints only (ie, try using
elision or not), and should not affect semantics.

Having a new nonstandard mutex type for the C++11 mutex semantics might
be worthwhile I think, given that those semantics are likely to not go
away, and I'd assume we'd get a decent amount of uses.

> In contrast, changing PTHREAD_MUTEX_DEFAULT to a new, unique value
> would be just fine.  Rather than meaning any particular thing fixed at
> compile time, it would just mean "do what you think is best for me".
> That's an ABI that will make sense in the future whether it results in
> the current or future PTHREAD_MUTEX_NORMAL or results in something
> else (that at least meets the POSIX mandate for PTHREAD_MUTEX_NORMAL).
> 
> > 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?
> 
> I object to environment variables for completely separate reasons.
> 
> > Which of these are true and which aren't?  Any other notable
> > consequences that are missing in the list above?
> 
> Aside from symbol versioning requirements for any kind of ABI
> addition, nothing pops to mind.
> 
> > 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.
> 
> I do think this is doable.

Okay.  I'll have a look at which steps would be necessary for that.


Torvald