This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] New condvar implementation that provides stronger ordering guarantees.
- From: Rich Felker <dalias at libc dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>, Marcus Shawcroft <marcus dot shawcroft at gmail dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Richard Henderson <rth at redhat dot com>, Carlos O'Donell <codonell at redhat dot com>, Mike Frysinger <vapier at gentoo dot org>, Chung-Lin Tang <chunglin_tang at mentor dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, Andreas Krebbel <krebbel at linux dot ibm dot com>, Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>, Chris Metcalf <cmetcalf at tilera dot com>, David Miller <davem at davemloft dot net>, Darren Hart <dvhart at infradead dot org>
- Date: Tue, 24 Feb 2015 12:31:16 -0500
- Subject: Re: [PATCH] New condvar implementation that provides stronger ordering guarantees.
- Authentication-results: sourceware.org; auth=none
- References: <1424456307 dot 20941 dot 122 dot camel at triegel dot csb> <20150222223722 dot GA23507 at brightrain dot aerifal dot cx> <1424690809 dot 22790 dot 32 dot camel at triegel dot csb> <20150223175939 dot GE23507 at brightrain dot aerifal dot cx> <1424714997 dot 22790 dot 40 dot camel at triegel dot csb>
On Mon, Feb 23, 2015 at 07:09:57PM +0100, Torvald Riegel wrote:
> > > > > + * EOWNERDEAD or ENOTRECOVERABLE when using robust mutexes. Unlike
> > > > > + for other errors, this can happen when we re-acquire the mutex; this
> > > > > + isn't allowed by POSIX (which requires all errors to virtually happen
> > > > > + before we release the mutex or change the condvar state), but there's
> > > > > + nothing we can do really.
> > > >
> > > > Likewise these are "shall fail" errors specified by POSIX, and while
> > > > it's not clearly written in the specification, it's clear that they
> > > > only happen on re-locking.
> > >
> > > Yes, they are "shall fail". I also agree that POSIX *should* make it
> > > clear that they can happen after releasing and when acquiring the mutex
> > > again -- but that's not what the spec says:
> > >
> > > "Except in the case of [ETIMEDOUT], all these error checks shall act as
> > > if they were performed immediately at the beginning of processing for
> > > the function and shall cause an error return, in effect, prior to
> > > modifying the state of the mutex[...]"
> >
> > OK, then I think that text is a bug. There's no way that mutex locking
> > errors could meaningful before the mutex is unlocked.
> >
> > > Until these two get clarified in the spec, I consider the comments
> > > correct. We can certainly extend them and document why we thing this
> > > behavior is The Right Thing To Do. But we need to document where we
> > > deviate from what the spec states literally.
> >
> > Yes. Would you like to submit the bug report or should I?
>
> If you have some time, please do.
And my report was a duplicate; this was already fixed:
http://austingroupbugs.net/view.php?id=749
Rich