Re: Update on freeze status of glibc 2.18?

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

> 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)?

I don't think that's necessary, though I'm not completely sure.  I had not
been thinking about PTHREAD_MUTEX_INITIALIZER earlier, but I think we can
handle that too.

Using new symbol versions across the board would be the "safest" in a
certain sense.  That is, safe from any errors in our reasoning about what
changes in implementation behavior are acceptable for old binaries to start
experiencing.  However, it would be significantly more hassle to implement
(nothing deep, just lots of trivia, but annoying), and it would be less
friendly to users in a general way.  That is, most programs don't know
about mutex types at all; they just use pthread_mutex_init with no
attributes and/or PTHREAD_MUTEX_INITIALIZER.  If building such a program
against a new libpthread results in a binary that requires users to have a
new libpthread, that is more hassle for people building and distributing
programs than if it doesn't.  We always say that you have no guarantee of
that sort of forward-compatibility and if you need to build compatible
binaries in general you must have a compilation environment that uses older
headers and DSOs.  But in practice, such incompatibilities are fairly rare
and most often on new or obscure interfaces so that the majority of
programs are not affected and sloppy procedures will work well enough for
those application-builders most of the time.  (A few years back, powerpc
changed the symbol version for printf, so approximately everything
everywhere became a compatibility issue.  But that was unusual.)

What we'd do is change both PTHREAD_MUTEX_NORMAL and PTHREAD_MUTEX_DEFAULT
to be two different new values.  (Since PTHREAD_MUTEX_NORMAL is today
defined as PTHREAD_MUTEX_TIMED_NP, we'd have to change
PTHREAD_MUTEX_TIMED_NP as well.  Similar to the situation with DEFAULT, I
think we should make NORMAL be its own value distinct from TIMED_NP rather
than just changing them both to the same new value.  That way we'll have
the option in the future to give NORMAL some different implementation that
meets its POSIX requirements but need not match the particulars of TIMED_NP
if programs are written to request that specifically for some reason.)

The old value (zero) would no longer be available by any public name, but
would be supported by the implementation as the COMPAT type.  Old binaries
requesting the COMPAT type could be given any new/future type that meets
the POSIX requirements for NORMAL.

PTHREAD_MUTEX_INITIALIZER would be changed to use the new DEFAULT value.
Thus new binaries could be given any new/future type that meets the POSIX
requirements for DEFAULT.

pthread_mutexattr_gettype would also need a new version, so that its compat
function makes a pthread_mutexattr_t set to new-DEFAULT or new-NORMAL
report back as old-NORMAL.  But nothing else should need a new symbol version.

I'm not entirely clear on what the requirements of NORMAL are that the new
elision-using types you have in mind would not meet.  So perhaps there is
some constraint that means that COMPAT could never have the behavior of the
new DEFAULT, in which case old binaries that use PTHREAD_MUTEX_INITIALIZER
rather than pthread_mutex_init could never get elision.

All of this needs some more thorough contemplation of possible vectors of
compatibility problems.  You're much better at thorough contemplation
than I am, so I'll rely on you. ;-)

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

A new type that says the semantic requirements on the implementation are
looser could be OK.  But that's assuming that the particulars of that
loosening wind up in the long run being useful in giving the implementation
more leeway to do things that are worthwhile for performance.

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

That certainly seems very reasonable.  Do you have a quick summary (or
pointer to something) of how the C++11 mutex semantics differ from the
POSIX mandate for PTHREAD_MUTEX_NORMAL?


Thanks,
Roland