A NOTE has been added to this issue.
======================================================================
http://austingroupbugs.net/view.php?id=121
======================================================================
Reported By: aas029
Assigned To: ajosey
======================================================================
Project: 1003.1(2008)/Issue 7
Issue ID: 121
Category: System Interfaces
Type: Enhancement Request
Severity: Comment
Priority: normal
Status: Under Review
Name: aas029
Organization:
User Reference:
Section: pthread_mutex_unlock
Page Number: using online version
Line Number: using online version
Final Accepted Text:
======================================================================
Date Submitted: 2009-07-12 08:48 UTC
Last Modified: 2009-07-13 08:47 UTC
======================================================================
Summary: robust mutex unlock by a thread that does not own
the mutex
Description:
The interface for pthread_mutex_lock(), _trylock(), _unlock() seems to have
a conflict between the following statements:
1. "If the mutex type is PTHREAD_MUTEX_NORMAL ... If a thread attempts to
unlock a mutex that it has not locked or a mutex which is unlocked,
undefined behavior results.
.....
If the mutex type is PTHREAD_MUTEX_DEFAULT, ... Attempting to unlock the
mutex if it was not locked by the calling thread results in undefined
behavior. "
AND:
2. "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."
The involved scenario is:
An attempt to unlock a robust mutex of type NORMAL or DEFAULT by a thread
that does not own it.
If I understand #2 above correctly, invoking the above scenario shall
result in EPERM. This is clearly a defined behavior. On the other hand, the
statements quoted in #1 above suggest the outcome for the same scenario
(among other ones) is undefined behavior. There is no distinction made for
robust mutexes.
Desired Action:
Update the wording of the statements quoted in #1 in the description of
this issue. Here is one possible suggestion:
If the mutex type is PTHREAD_MUTEX_NORMAL ... If a thread attempts to
unlock a mutex which is unlocked, undefined behavior results. Further, if a
thread attempts to unlock a mutex that it has not locked and the mutex is
not robust, undefined behavior results.
.....
.....
If the mutex type is PTHREAD_MUTEX_DEFAULT, ... If a thread attempts to
unlock a mutex that it has not locked and the mutex is not robust,
undefined behavior results.
======================================================================
----------------------------------------------------------------------
(0000158) geoffclare (reporter) - 2009-07-13 08:47
http://austingroupbugs.net/view.php?id=121#c158
----------------------------------------------------------------------
These mutex type descriptions also appear on the
pthread_mutexattr_gettype() page; it also needs to be updated to
take robust mutexes into account. In addition, that page talks
about re-locking without taking into account the difference between
pthread_mutex_lock() and pthread_mutex_trylock().
It would be good if the duplication could be avoided, by having
the mutex type descriptions appear on one of these pages and just
referring to them on the other.
|