|Anonymous | Login | Signup for a new account||2018-04-22 23:37 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0000121||[1003.1(2008)/Issue 7] System Interfaces||Comment||Enhancement Request||2009-07-12 08:48||2013-04-16 13:06|
|Priority||normal||Resolution||Accepted As Marked|
|Final Accepted Text||Note: 0000159|
|Summary||0000121: robust mutex unlock by a thread that does not own the mutex|
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. "
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.
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.
|Attached Files||Mutex – Summary (POSIX 2004).pdf [^] (28,957 bytes) 2009-07-13 21:28|
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.
edited on: 2009-10-13 08:45
The standard is unclear on this issue, and no conformance
distinction can be made between alternative implementations based
on this. This is being referred to the sponsor.
Notes to the Editor (not part of this interpretation):
This includes a fix to address the issues identified in the
original report and in Note: 0000158. This also includes a fix for
an omission in the EPERM error on the pthread_mutex_lock()
On the pthread_mutexattr_gettype() page, remove the descriptions from
the list of mutex types (lines 53481 to 53504), leaving just the four
type names. After the list of names add:
The mutex type affects the behavior of calls which lock and
unlock the mutex. See [xref to pthread_mutex_lock()] for details.
An implementation may map PTHREAD_MUTEX_DEFAULT to one of the
other mutex types.
On the pthread_mutex_lock() page, replace the first five paragraphs
of the description (lines 52690 to 52711) with:
The mutex object referenced by mutex shall be locked by a call to
pthread_mutex_lock() that returns zero or EOWNERDEAD.
If the mutex is already locked by another thread, the calling
thread shall block until the mutex becomes available. This
operation shall return with the mutex object referenced by mutex
in the locked state with the calling thread as its owner.
If a thread attempts to relock a mutex that it has already locked,
pthread_mutex_lock() shall behave as described in the Relock column
of the following table. If a thread attempts to unlock a mutex
that it has not locked or a mutex which is unlocked,
pthread_mutex_unlock() shall behave as described in the Unlock When
Not Owner column of the following table.
______________________________________________________________________ | Mutex Type Robustness Relock Unlock When Not Owner | |_____________________________________________________________________| | | | normal non-robust deadlock undefined behavior | | | | normal robust deadlock error returned | | | | errorcheck either error returned error returned | | | | recursive either recursive error returned | | (see below) | | | | default non-robust undefined undefined behavior | | behavior | | | | default robust undefined error returned | | behavior | |_____________________________________________________________________|
1. If the mutex type is PTHREAD_MUTEX_DEFAULT, the behavior of
pthread_mutex_lock() may correspond to one of the three other
standard mutex types as described in the table above. If it
does not correspond to one of those three, the behavior is
undefined for the cases marked .
Where the table indicates recursive behavior, the mutex shall
maintain the concept of a lock count. When a thread successfully
acquires a mutex for the first time, the lock count shall be set
to one. Every time a thread relocks this mutex, the lock count
shall be incremented by one. Each time the thread unlocks the
mutex, the lock count shall be decremented by one. When the lock
count reaches zero, the mutex shall become available for other
threads to acquire.
At line 52763 change the description of EPERM from:
The mutex type is PTHREAD_MUTEX_ERRORCHECK or the mutex is a
robust mutex, and the current thread does not own the mutex.
The mutex type is PTHREAD_MUTEX_ERRORCHECK or
PTHREAD_MUTEX_RECURSIVE, or the mutex is a robust mutex, and the
current thread does not own the mutex.
I find a table like the one suggested by geoffclare to be the best way to summaries the info for the reader but more importantly make sure all cases are covered and in a consistent manner.
In fact, I had produced such table for myself which covers all possible operations on mutexes, mutex state, mutex current owner and mutex type. I have this in pdf form for the 2004 version (doesn't reflect 2008 updates but I'll upload it as an example). I'm not familiar with the standard's update process and format restriction. I can share my upcoming 2008 version if the standard is open to such summary suggestions. Actually I discovered the issue reported while trying to fill a 2008 version of the table.
|2009-07-12 08:48||user46||New Issue|
|2009-07-12 08:48||user46||Status||New => Under Review|
|2009-07-12 08:48||user46||Assigned To||=> ajosey|
|2009-07-12 08:48||user46||Name||=> aas029|
|2009-07-12 08:48||user46||Section||=> pthread_mutex_unlock|
|2009-07-12 08:48||user46||Page Number||=> using online version|
|2009-07-12 08:48||user46||Line Number||=> using online version|
|2009-07-13 08:47||geoffclare||Note Added: 0000158|
|2009-07-13 11:22||geoffclare||Note Added: 0000159|
|2009-07-13 20:47||user46||Issue Monitored: user46|
|2009-07-13 21:15||user46||Note Added: 0000161|
|2009-07-13 21:28||user46||File Added: Mutex – Summary (POSIX 2004).pdf|
|2009-08-13 16:27||nick||Page Number||using online version => 1638|
|2009-08-13 16:27||nick||Line Number||using online version => 52698|
|2009-08-13 16:27||nick||Interp Status||=> ---|
|2009-08-20 15:14||ajosey||Interp Status||--- => Pending|
|2009-08-20 15:14||ajosey||Final Accepted Text||=> Note: 0000159|
|2009-08-20 15:14||ajosey||Note Added: 0000198|
|2009-08-20 15:14||ajosey||Status||Under Review => Interpretation Required|
|2009-08-20 15:14||ajosey||Resolution||Open => Accepted As Marked|
|2009-09-17 15:41||nick||Interp Status||Pending => Proposed|
|2009-10-13 08:45||ajosey||Note Edited: 0000159|
|2009-10-13 08:45||ajosey||Note Deleted: 0000198|
|2009-10-13 08:46||ajosey||Interp Status||Proposed => Approved|
|2010-09-21 11:10||geoffclare||Tag Attached: tc1-2008|
|2013-04-16 13:06||ajosey||Status||Interpretation Required => Closed|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|