Re: C11 threads ABI - mtx_t and cnd_t types

[Rich Felker <dalias at libc dot org>]

On Tue, Oct 07, 2014 at 03:59:08PM +0200, Torvald Riegel wrote:
> > > I don't see anything in C11 that would agree with the opinion of the
> > > Austin Group.  I think C11 should do what C++11 states explicitly: you
> > > get undefined behvaior if a mutex is owned by a thread that terminates.
> > > (That is, what you also stated in Note 0001848 in the POSIX BZ above.)
> > 
> > It's just what you get when reading the requirements as written
> > without considering termination-while-owner as a special case:
> > mtx_lock cannot succeed unless the mutex is not already locked or the
> > current thread is already the owner.
> 
> C11 states: "The mtx_lock function blocks until it locks the mutex
> pointed to by mtx."  The case of what happens when a thread terminates
> is simply undefined.

In the absence of text saying something special happens when a thread
terminates, I don't think you can argue that this is UB; the mutex
just retains whatever state it already had (being locked) and there is
no longer any thread which is its owner. This is unfortunate and
undesirable, I agree, but I would approach WG14 with the idea that
this is an oversight and unintentional side effect of lack of
specification (note: there are already several bugs in C11 that are
presumably going to be fixed) rather than trying to weasel out some
interpretation that it's already undefined.

> > > preferably in my opinion, documentation that glibc does not implement
> > > this requirement for non-robust locks.  This is now
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=17463
> > 
> > If it's a requirement and we can't get it relaxed for the next issue,
> > I think glibc should implement the required behavior rather than going
> > back to the old days of flaunting non-compliance whenever someone
> > disagrees with a decision made in the standards process. It's really
> > not hard to do, and the code is already there -- it's the exact same
> > code that's used for robust mutexes. If I remember correctly, glibc is
> > using separate code paths (and lock designs!) for robust and
> > non-robust, only putting the tid in the futex slot for robust and
> > using a separate owner slot for non-robust, so this may complicate
> > things somewhat; on the other hand, if there's no benefit to having
> > the two separate designs, it might actually help clean things up to
> > remove the redundant one. (My guess: maybe it was an attempt at
> > supporting targets without atomic compare-and-swap?)
> 
> I wouldn't use the algorithm of robust mutexes to implement the
> thread-ID ABA avoidance.

Do you have a reason in mind? IMO it's simple and it offloads all the
heavy work to the (unlikely) case of thread termination while owning
mutexes, where the kernel does the work for you (but it would be just
as easy to do in userspace, anyway, as part of pthread_exit).

Rich