Re: Update on freeze status of glibc 2.18?

[Roland McGrath <roland at hack dot frob dot com>]

> 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.  Otherwise newly-built programs would
become incompatible with older shared libraries but not say so in
their version requirements.  (You probably don't really need a
separate compatibility entry point, just an alias with the old,
non-default symbol version.)

> 2) Don't support elision with (nested) trylock because it can't be done
> without changing the ABI; it would violate POSIX semantics.

We can't ever do anything that breaks the semantics like this at all.
It's possibly acceptable only if it is enabled by a new, non-default,
non-standard type.  But that would be a new ABI and a new symbol
version for at least pthread_mutexattr_settype.

> 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.  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.

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.


Thanks,
Roland