Re: [RFC] Lock elision implementation guidelines

[Rich Felker <dalias at aerifal dot cx>]

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

Rich