Re: Update on freeze status of glibc 2.18?

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

> Do you know of any source that defines the TIMED_NP semantics in detail?

No.  As the name implies, it's a nonstandard type.  Given that it's always
been another name for NORMAL, I think it's reasonable to say that what we
always meant was that it has (quite loose) semantic guarantees of NORMAL
and no others.  But the fact that there was ever this other name suggests
perhaps someone had something else in mind.

Carlos's supposition that TIMED_NP means that unbounded calls like
pthread_mutex_lock can ever "time out" seems wholly implausible to me.
That's a clear violation of the POSIX semantics for any standard type.

> I haven't found anything clarifying whether they should behave like
> DEFAULT or like NORMAL.

I don't understand what distinction you have in mind here.  POSIX defines
NORMAL basically by saying it doesn't necessarily do any of the things that
the other POSIX-standard types do.  (I don't think it can properly be
construed to say that it behaves any particular way on deadlock, such as
deadlocking; EDEADLK is specified as a "may fail".  Perhaps that is
debatable; it probably merits an interpretation request.)  It defines
DEFAULT as the implementation's choice of one of the POSIX-standard types
(including NORMAL), or some other implementation-defined type.

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

That's a very good point!  I knew there was some reason I felt the need to
add that caveat about thinking thoroughly. ;-)

> 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 think it sounds good.  Today I'm not feeling especially competent to
confirm it has no holes.

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

I'll try to grok this next week.

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

OK.


Thanks,
Roland