Re: C11 threads ABI - mtx_t and cnd_t types

[Torvald Riegel <triegel at redhat dot com>]

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

I think the resolution should be either an implementation of the
requested behavior for recursive locks (and non-robust PI too?), or,
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

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

> in which case
> the expandability is probably worth a lot more than the size savings
> (expandability that requires allocation rather sucks, since there's
> probably no way an application can deal with failure to create a
> mutex, especially for mutexes that are intended to be "static" ones
> but which, because C11 lacks static allocation, require call_once and
> mtx_init).

Expendability would be a best-effort thing feature, aimed at potential
performance increases rather than a necessity for correctness.