This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc -- ISO C11 threads Proposal
- From: Rich Felker <dalias at aerifal dot cx>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Kevin Cox <kevincox at kevincox dot ca>, libc-alpha at sourceware dot org
- Date: Mon, 31 Mar 2014 01:50:03 -0400
- Subject: Re: glibc -- ISO C11 threads Proposal
- Authentication-results: sourceware.org; auth=none
- References: <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> <1396037667 dot 19076 dot 4026 dot camel at triegel dot csb> <20140328202229 dot GQ26358 at brightrain dot aerifal dot cx> <1396039607 dot 19076 dot 4106 dot camel at triegel dot csb>
On Fri, Mar 28, 2014 at 09:46:47PM +0100, Torvald Riegel wrote:
> 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?
Too late -- the interpretation was just approved:
http://austingroupbugs.net/view.php?id=755
But perhaps this could get changed for the next issue of the standard
if you can convince them that the currently-required behavior is too
costly and not useful.
I realized there's an alternate solution to the problem for
non-process-shared mutexes: simply keep a count of recursive or
error-checking mutexes the current thread owns in its TLS. If, on
exit, this count is nonzero, don't actually exit but instead leave the
tid permanently tied up until the process exits. (This requires
emulating thread exit for pthread_join to work.)
This doesn't work for process-shared mutexes however: once the process
exits, the tid could be reused in a completely different process.
Rich