This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc -- ISO C11 threads Proposal


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]