Anonymous | Login | 2024-04-19 22:07 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
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 | ||
Reporter | user46 | View Status | public | ||||
Assigned To | ajosey | ||||||
Priority | normal | Resolution | Accepted As Marked | ||||
Status | Closed | ||||||
Name | aas029 | ||||||
Organization | |||||||
User Reference | |||||||
Section | pthread_mutex_unlock | ||||||
Page Number | 1638 | ||||||
Line Number | 52698 | ||||||
Interp Status | Approved | ||||||
Final Accepted Text | Note: 0000159 | ||||||
Summary | 0000121: 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. |
||||||
Tags | tc1-2008 | ||||||
Attached Files | Mutex – Summary (POSIX 2004).pdf [^] (28,957 bytes) 2009-07-13 21:28 | ||||||
|
Notes | |
(0000158) geoffclare (manager) 2009-07-13 08:47 |
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. |
(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. |
Issue History | |||
Date Modified | Username | Field | Change |
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 |