Re: glibc -- ISO C11 threads Proposal

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2014-03-28 at 16:22 -0400, Rich Felker wrote:
> On Fri, Mar 28, 2014 at 09:14:27PM +0100, Torvald Riegel wrote:
> > On Fri, 2014-03-28 at 01:36 -0400, Rich Felker wrote:
> > > FYI, glibc is currently wasting at least one slot. There's no reason
> > > to have separate futex and owner fields, and doing so actually
> > > precludes making recursive and error-checking mutexes reentrant. Since
> > > my implementation doesn't waste an extra slot on owner, it has enough
> > > slots in the 32-bit structure to store both prev/next pointers for
> > > robust mutexes, making them O(1) instead of O(n). This will turn out
> > > to be even more important for solving the tid reuse issue (where a
> > > mutex that was left locked by a thread that exited could be
> > > misinterpreted by a new thread that happens to get the same tid); as
> > > far as I can tell, the only reasonable solution is implementing
> > > recursive and error-checking mutexes internally as robust mutexes, but
> > > assigning them a permanent dummy owner them rather than giving
> > > EOWNERDEAD when they're found in "owner died" state.
> > 
> > If a recursive mutex is still locked by a thread when the thread exits,
> > this should result in undefined behavior.
> 
> That was the interpretation I hoped for too, but the Austin Group
> seems to have rejected it. If glibc developers would like to push to
> have this issue reconsidered, I would be very happy. I think it's
> stupid to have to support the case where a thread exits with a mutex
> locked.

Can you point me to the Austin Group issue?

> > I don't think tracking which
> > recursive mutexes a thread has acquired (in the sense of being able to
> > enumerate them by starting at some thread-specific variable) is
> > something we'd want, given the overheads that this essentially has.  And
> > if you don't track them, you can't prevent TID/owner reuse because
> > you'll eventually run out of space for where to store this.
> 
> Indeed. Tracking the recursive/error-checking mutexes owned is the
> only practical solution. It's not expensive (i.e. it's O(1)) as long
> as you have space for a doubly-linked list, but it's an utter joke if
> you only have room for singly-linked.

Even if there's space for prev/next in the mutex, you end up with
writing more stuff to the mutex, which is a shared data structure.  This
will, to some extent, increase the chance of cache misses with other
threads spin-waiting on the mutex (depending on the hardware and the
kind of spinning, of course).

> > Note that I haven't checked what POSIX says about this case (if it
> > does).  AFAIK, C11 leaves it unspecified (which isn't surprising given
> > that it tries to specify locks with just 30 lines of text...)
> > But IMO, locks should have a narrow contract, so that the implementation
> > can actually try to be efficient, and doesn't have to do error checking
> > or such
> 
> Normal mutexes have the "narrow contract" you want. Recursive and
> error-checking mutexes are heavy.

Well, default mutexes do.  If we consider the TSX lock elision case,
then C++11 non-recursive mutexes are actually the easiest to build
efficient (e.g., due to trylock semantics).  I'm fine with
error-checking mutexes being heavyweight, but why recursive mutexes?

> The whole idea of doing mutexes as a
> common type with attributes rather than separate types (so normal
> mutex could be a single int) was idiotic.

I think C might play a part here.  If there's no overloading based on
types, and no per-class function members, then you'll end up with longer
names for the functions.  Also, you can't use a recursive mutex in code
that accepts any mutex -- but whether that is really a good use case is
something I'm not sure about.