This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Lock elision implementation guidelines
On Mon, Feb 25, 2013 at 04:54:44PM -0500, Rich Felker wrote:
> On Mon, Feb 25, 2013 at 01:26:03PM -0800, Roland McGrath wrote:
> > > PTHREAD_MUTEX_RECURSIVE: No. While correctly-used recursive lock/unlock
> > > do work, this mutex type is specified to return an error if a thread
> > > unlocks a mutex that is not acquired or not acquired by this thread.
> >
> > This may merit a POSIX interpretation request. The DESCRIPTION section for
> > pthread_mutex_*lock does say, in the paragraph about
> > PTHREAD_MUTEX_RECURSIVE, "If a thread attempts to unlock a mutex that it
> > has not locked or a mutex which is unlocked, an error shall be returned."
> > But the ERRORS section does not list any error code for this case. If it
> > were to, and it were listed as a "may fail" rather than a "shall fail",
> > then there could be some flexibility here.
>
> I think the bug is simply that the following text is missing the
> recursive case:
>
> The pthread_mutex_unlock() function shall fail if:
>
> [EPERM]
> The mutex type is PTHREAD_MUTEX_ERRORCHECK or the mutex is a robust
> mutex, and the current thread does not own the mutex.
>
> In any case, the "shall fail" is pretty clear. I've send a defect
> report:
>
> http://austingroupbugs.net/view.php?id=665
And apparently this was a duplicate of an issue already fixed for the
TC: http://austingroupbugs.net/view.php?id=121
Rich