This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc -- ISO C11 threads Proposal
- From: Torvald Riegel <triegel at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, Kevin Cox <kevincox at kevincox dot ca>, libc-alpha at sourceware dot org
- Date: Fri, 28 Mar 2014 21:14:27 +0100
- Subject: Re: glibc -- ISO C11 threads Proposal
- Authentication-results: sourceware.org; auth=none
- References: <53260E7E dot 8070308 at kevincox dot ca> <1395771092 dot 19076 dot 1236 dot camel at triegel dot csb> <5331C7EA dot 6050407 at redhat dot com> <1395777699 dot 19076 dot 1469 dot camel at triegel dot csb> <20140325212732 dot GC26358 at brightrain dot aerifal dot cx> <53337E8B dot 50508 at kevincox dot ca> <20140327015642 dot GF26358 at brightrain dot aerifal dot cx> <1395937708 dot 19076 dot 2997 dot camel at triegel dot csb> <20140327170447 dot GJ26358 at brightrain dot aerifal dot cx> <53350719 dot 6090401 at redhat dot com> <20140328053615 dot GM26358 at brightrain dot aerifal dot cx>
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. 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.
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