Re: glibc -- ISO C11 threads Proposal

[Rich Felker <dalias at aerifal dot cx>]

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.

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

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

Perhaps I should just write a tiny mutex library based on C11 atomics
and futex for applications to use. (This is not too hard, but also
non-trivial because you have to support self-synchronized destruction
in order for it to be useful.)

Rich