 Relationships |
|
| Anonymous | Login | 2024-04-18 22:00 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 | ||
| 0001115 | [1003.1(2016/18)/Issue7+TC2] System Interfaces | Editorial | Clarification Requested | 2017-01-13 14:41 | 2019-10-30 11:26 | ||
| Reporter | Florian Weimer | View Status | public | ||||
| Assigned To | |||||||
| Priority | normal | Resolution | Accepted As Marked | ||||
| Status | Applied | ||||||
| Name | Florian Weimer | ||||||
| Organization | Red Hat | ||||||
| User Reference | |||||||
| Section | pthread_mutex_lock | ||||||
| Page Number | 1672 | ||||||
| Line Number | 1672 | ||||||
| Interp Status | --- | ||||||
| Final Accepted Text | See Note: 0004056 | ||||||
| Summary | 0001115: Lock acquisition state after pthread_mutex_lock with EOWNERDEAD | ||||||
| Description |
The text currently says: “ If mutex is a robust mutex and the owning thread terminated while holding the mutex lock, a call to pthread_mutex_lock() may return the error value [EOWNERDEAD] even if the process in which the owning thread resides has not terminated. In these cases, the mutex is locked by the thread but the state it protects is marked as inconsistent. ” It is unclear to which thread “the thread” in the last sentence refers. The current text goes on with: “ The application should ensure that the state is made consistent for reuse and when that is complete call pthread_mutex_consistent(). If the application is unable to recover the state, it should unlock the mutex without a prior call to pthread_mutex_consistent(), after which the mutex is marked permanently unusable. ” Due to the ambiguity above, it is unclear whether the current thread (which calls pthread_mutex_consistent()) has acquired the lock after the call, and whether it is correct to call pthread_mutex_unlock() afterwards. |
||||||
| Desired Action |
I suggest to replace “the thread” with “the thread which has called pthread_mutex_lock() resulting in an [EOWNERDEAD] error”. As a result, the mutex is in the acquired state, and it remains so after a call pthread_mutex_consistent(). Then it's allowed to call pthread_mutex_unlock() whether or not pthread_mutex_consistent() has been called. Another implication is that because the new thread acquires the lock, only one thread can return [EOWNERDEAD], and the others will block. I do not know if this matches actual implementation practice, but it is the only way robust mutexes can recovery without external synchronization. |
||||||
| Tags | tc3-2008 | ||||||
| Attached Files | |||||||
|
|
|||||||
|
Relationships |
|
|
Notes |
|
|
(0003542) geoffclare (manager) 2017-01-13 15:03 |
I have no objection to improving the text here, but the localised ambiguity disappears when reading the DESCRIPTION section as a whole, because the first sentence clearly states "The mutex object referenced by mutex shall be locked by a call to pthread_mutex_lock() that returns zero or [EOWNERDEAD]." |
|
(0004056) nick (manager) 2018-07-19 15:58 edited on: 2018-07-19 16:01 |
On page 1672 line 54500 change: If mutex is a robust mutex and the owning thread terminated while holding the mutex lock, a call to pthread_mutex_lock() may return the error value [EOWNERDEAD] even if the process in which the owning thread resides has not terminated. In these cases, the mutex is locked by the thread but the state it protects is marked as inconsistent. to: If mutex is a robust mutex and the owning thread terminated while holding the mutex lock, a call to pthread_mutex_lock() may return the error value [EOWNERDEAD] even if the process in which the owning thread resides has not terminated. In these cases, the mutex shall be locked by the calling thread but the state it protects is marked as inconsistent. |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2017-01-13 14:41 | Florian Weimer | New Issue | |
| 2017-01-13 14:41 | Florian Weimer | Name | => Florian Weimer |
| 2017-01-13 14:41 | Florian Weimer | Organization | => Red Hat |
| 2017-01-13 14:41 | Florian Weimer | Section | => pthread_mutex_lock |
| 2017-01-13 14:41 | Florian Weimer | Page Number | => unknown |
| 2017-01-13 14:41 | Florian Weimer | Line Number | => unknown |
| 2017-01-13 14:45 | Florian Weimer | Issue Monitored: Florian Weimer | |
| 2017-01-13 15:03 | geoffclare | Note Added: 0003542 | |
| 2018-07-19 15:58 | nick | Page Number | unknown => 1672 |
| 2018-07-19 15:58 | nick | Line Number | unknown => 1672 |
| 2018-07-19 15:58 | nick | Interp Status | => --- |
| 2018-07-19 15:58 | nick | Note Added: 0004056 | |
| 2018-07-19 15:58 | nick | Status | New => Resolved |
| 2018-07-19 15:58 | nick | Resolution | Open => Accepted As Marked |
| 2018-07-19 15:59 | nick | Final Accepted Text | => See Bugnote:0004056 |
| 2018-07-19 15:59 | nick | Final Accepted Text | See Bugnote:0004056 => See Note: 0000405 |
| 2018-07-19 16:00 | nick | Tag Attached: tc3-2008 | |
| 2018-07-19 16:00 | nick | Note Edited: 0004056 | |
| 2018-07-19 16:01 | nick | Note Edited: 0004056 | |
| 2018-07-19 16:02 | nick | Final Accepted Text | See Note: 0000405 => See Note: 0004056 |
| 2019-10-30 11:26 | geoffclare | Status | Resolved => Applied |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
