This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Lock elision implementation guidelines
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Mon, 25 Feb 2013 13:26:03 -0800 (PST)
- Subject: Re: [RFC] Lock elision implementation guidelines
- References: <1360527652.3065.11521.camel@triegel.csb>
> 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.