[PATCH] New condvar implementation that provides stronger ordering guarantees.

[Rich Felker]

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