(0000159)
geoffclare (manager)
2009-07-13 11:22
edited on: 2009-10-13 08:45
|
Interpretation response
------------------------
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.
Rationale:
-------------
None.
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()
page.
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[1] |
| behavior[1] |
| |
| default robust undefined error returned |
| behavior[1] |
|_____________________________________________________________________|
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 [1].
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.
to:
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.
|
(0000161)
user46
2009-07-13 21:15
|
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. |
Mutex – Summary (POSIX 2004).pdf [^] (28,957 bytes) 2009-07-13 21:28 
