Re: C11 threads ABI - mtx_t and cnd_t types

[Torvald Riegel <triegel at redhat dot com>]

On Tue, 2014-10-07 at 09:26 -0400, Rich Felker wrote:
> On Tue, Oct 07, 2014 at 02:51:47PM +0200, Torvald Riegel wrote:
> > On Mon, 2014-10-06 at 13:58 -0400, Rich Felker wrote:
> > > On Mon, Oct 06, 2014 at 03:17:59PM +0200, Torvald Riegel wrote:
> > > > On Sat, 2014-08-30 at 22:52 -0400, Rich Felker wrote:
> > > > > Another issue I have on the ABI for C11 threads pertains to the types
> > > > > for mtx_t and cnd_t. My understanding, and I agree with this, is that
> > > > > it was already decided to use the same underlying sizes/alignment, and
> > > > > for now representations, as the corresponding POSIX types.
> > > > 
> > > > I don't remember a decision being made rather than just people
> > > > expressing their opinion at that time, but maybe I'm wrong.
> > > > 
> > > > Anyway, for mtx_t I'm starting to wonder whether a fresh start would
> > > > indeed be better, with some additional room for expanding the lock
> > > > representation to state elsewhere.  (That is, mtx_t would at least be
> > > > pointer-sized.)
> > > > The reason for this is the current discussion around the barrier
> > > > semantics.  It is slowly moving, and I'm concerned about the Austin
> > > > Group deciding to stick to the less efficient spec for mutexes after a
> > > > long discussion -- which would leave us with larger-than-necessary mtx_t
> > > > while not using the pthread_mutex_t implementation anyway.
> > > 
> > > I question whether it's "much larger than necessary", especially if
> > > the C committee does not decide to make changes with regard to
> > > orphaned mutexes (see http://austingroupbugs.net/view.php?id=755),
> > 
> > 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.

> To nullify this (fundamental)
> rule in the special case where the owner has terminated, you need
> special language either making the whole thing UB, or specifically
> addressing the possibility that mtx_lock will spuriously succeed in
> this case.

I disagree.  But WG14 will have to sort this out.

> > I think the resolution should be either an implementation of the
> > requested behavior for recursive locks (and non-robust PI too?), or,
> 
> And for error-checking locks.

Agreed.

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