Re: Update on freeze status of glibc 2.18?

[Torvald Riegel <triegel at redhat dot com>]

On Thu, 2013-06-20 at 16:09 -0700, Roland McGrath wrote:
> 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.

Do you know of any source that defines the TIMED_NP semantics in detail?
I haven't found anything clarifying whether they should behave like
DEFAULT or like NORMAL.

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

That's a good idea, thanks.

What I don't understand in your plan is how we deal with the case that
we have a PTHREAD_MUTEX_INITIALIZER in a program built against new glibc
headers, but executed with an older glibc version.  In this case, the
new type values coming from the initializer wouldn't be understood by
the old pthread_mutex_lock(), for example.

> 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 need to think about this more, but could we keep the initializer at
the old value (zero)?  We do not have an initializer for NORMAL, so
there's no aliasing issue on the initializer side between NORMAL and
DEFAULT; one needs to go through settype() to request NORMAL.

In settype(), we would translate from the old value for NORMAL (zero) to
an internal new NORMAL_COMPAT type, and vice-versa in gettype().  This
would allow us to treat initialized mutexes that still have the old
value (zero) as type as the DEFAULT-typed mutexes that they are.  We
would give DEFAULT a new type and not translate it, but it would have
the same semantics as the zero-value type.

Thus, we would need new settype/gettype symbol versions, but just to be
able to parse the new DEFAULT.  Old binaries would still use the old
value for DEFAULT (zero) if using settype(), so they would get NORMAL
semantics instead (which is fine) and couldn't use elision.  But in
turn, old binaries that use just the initializers could make use of
elision, because we disambiguate explicit requests for NORMAL via
settype().

Does this sound reasonable?  Or are there any holes in this approach?

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

I've summarized the differences between the semantics (and what it means
for lock elision implemented with HTMs) in the guidelines wiki page:
http://sourceware.org/glibc/wiki/LockElisionGuide

Let me know if something isn't clear there.

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

They're briefly described in the guidelines (see link above) too.  I'm
not quite sure yet about some of the C11 requirements, but it looks
pretty close to DEFAULT to me.  C++11 is nicer to lock elision than
default, because certain trylock() uses aren't allowed.

Torvald