Re: C11 threads ABI - mtx_t and cnd_t types

[Rich Felker <dalias at libc dot org>]

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

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

> > since you need room for a linked list to deal with the tid-reuse
> > issue. I don't see a way to make a mutex any smaller than what you
> > have on 32-bit targets now without some hacks like cramming the mutex
> > type into the upper bits of the lock count or something. If you were
> > talking about a 50% or 75% size saving, this might be appealing, but I
> > think at best you'd be looking at shaving off one field,
> 
> I think for C11 one pointer-sized field plus a 32b counter is
> sufficient.  If we want to have extra space, like perhaps for spin-wait
> or elision tuning state, we could give it one extra 32b field.  That's
> 8/12 -- 12/16B for C11 (32b -- 64b min/extra) vs. 24 -- 40 as we have
> now on x86, for example.

I was assuming the need to keep a linked list for preventing false
ownership via tid reuse. BTW, in that case, since you'd be reusing the
robust mutex mechanism, you need the layouts (or at least the offset
between the linked lists pointers and the futex) to match between
pthread_mutex_t and mtx_t, or they can't reside together in a robust
list.

Rich