View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000722 | 1003.1(2013)/Issue7+TC1 | Base Definitions and Headers | public | 2013-07-15 15:52 | 2019-06-10 08:55 |
| Reporter | chrubis | Assigned To | ajosey | ||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Cyril Hrubis | ||||
| Organization | SUSE | ||||
| User Reference | |||||
| Section | pthread_rwlock_rdlock/pthread_rwlock_wrlock (XSH, 3 System Interfaces) | ||||
| Page Number | 1689, 1697 | ||||
| Line Number | 54657-54658, 54659-54662, 54885 | ||||
| Interp Status | Approved | ||||
| Final Accepted Text | 0000722:0001684 | ||||
| Summary | 0000722: pthread_rwlock writers preferrence | ||||
| Description | While working on LTP (Linux Test Project) I've found that a few Open Posix testcases [1] fails because glibc implementation does not preffer writer locks over reader locks. Now upon investigation I've found that the specification seems to contradicts wether this is required. The pthread_rwlock_rdlock says: ... The calling thread acquires the read lock if a writer does not hold the lock and there are no writers blocked on the lock. ... For the case of TPS and certain scheduling policies it's refined only for threads with equal or higher priority: ... If the Thread Execution Scheduling option is supported, and the threads involved in the lock are executing with the scheduling policies SCHED_FIFO or SCHED_RR, the calling thread shall not acquire the lock if a writer holds the lock or if writers of higher or equal priority are blocked on the lock; otherwise, the calling thread shall acquire the lock. ... While the pthread_rwlock_wrlock says: ... Implementations may favor writers over readers to avoid writer starvation. ... While the first suggests that it's compulsory the second clearly states that it's optional. As Rich Felker pointed out on glic mailing list [2] there are also problems with recursive locks. If thread acquired read lock and there is a writer locked on the lock an attempt to acquire read lock by the first thread will lead to dead lock (which is not avoidable unless we keep track of all readers that has acquired the lock). [1] https://github.com/linux-test-project/ltp testcases/open_posix_testsuite/conformance/interfaces/pthread_rwlock_rdlock/2-1.c testcases/open_posix_testsuite/conformance/interfaces/pthread_rwlock_rdlock/2-2.c [2] http://sourceware.org/ml/libc-alpha/2013-07/msg00244.html | ||||
| Desired Action | Clarification whether write preference is required and if so under which conditions. | ||||
| Tags | tc2-2008 | ||||
|
|
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: ------------- Changes were made to the read locks in Issue 6, that should also be represented in the write lock specification regarding read/write precedence. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- On Page 1697: Remove line 54885: Implementations may favor writers over readers to avoid writer starvation. |
|
|
The proposed interpretation does not resolve the problem with recursive read locks. If recursive read locks are supposed to work (which is clearly the case), then pthread_rwlock_rdlock() must not block if the caller already holds a read lock, even if a writer is blocked. The check whether the caller holds a read lock can be exact but this requires memory allocation in pthread_rwlock_rdlock() and may cause it to fail unexpectedly. Therefore, it may be appropriate to use a check that uses a fixed amount of memory per thread but may incorrectly declare that a thread holds a read lock. For example, FreeBSD tracks whether a thread hold a read lock on any rwlock at all. The extreme, as in glibc, is to pretend a thread always holds a read lock, so always use readers preference. Due to problems like these, applications should probably be encouraged to use mutexes unless rwlocks are needed for performance reasons. |
|
|
The recursive locks issue will be dealt with in 0000720. All we are doing for this bug is removing a line that was retained from SUSv2 in error when SUSv2 and POSIX.1j were merged into SUSv3/POSIX.1-2001. |
|
|
Interpretation Proposed 6 Sep 2013 |
|
|
Interpretation approved 14 October 2013 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-07-15 15:52 | chrubis | New Issue | |
| 2013-07-15 15:52 | chrubis | Status | New => Under Review |
| 2013-07-15 15:52 | chrubis | Assigned To | => ajosey |
| 2013-07-15 15:52 | chrubis | Name | => Cyril Hrubis |
| 2013-07-15 15:52 | chrubis | Organization | => SUSE |
| 2013-07-15 15:52 | chrubis | Section | => pthread_rwlock_rdlock/pthread_rwlock_wrlock (XSH, 3 System Interfaces) |
| 2013-07-15 15:52 | chrubis | Page Number | => unknown |
| 2013-07-15 15:52 | chrubis | Line Number | => unknown |
| 2013-07-18 15:50 | msbrown | Project | 1003.1(2008)/Issue 7 => 1003.1(2013)/Issue7+TC1 |
| 2013-07-18 15:52 | msbrown | Page Number | unknown => 1689, 1697 |
| 2013-07-18 15:52 | msbrown | Line Number | unknown => 54657-54658, 54659-54662, 54885 |
| 2013-07-18 15:52 | msbrown | Interp Status | => --- |
| 2013-07-18 16:06 | eblake | Relationship added | related to 0000720 |
| 2013-07-18 16:09 | msbrown | Note Added: 0001684 | |
| 2013-07-18 16:10 | msbrown | Interp Status | --- => Pending |
| 2013-07-18 16:10 | msbrown | Final Accepted Text | => 0000722:0001684 |
| 2013-07-18 16:10 | msbrown | Status | Under Review => Interpretation Required |
| 2013-07-18 16:10 | msbrown | Resolution | Open => Accepted As Marked |
| 2013-07-18 16:11 | msbrown | Tag Attached: tc2-2008 | |
| 2013-07-18 16:12 | msbrown | Note Edited: 0001684 | |
| 2013-07-18 22:11 | jilles | Note Added: 0001687 | |
| 2013-07-19 08:59 | geoffclare | Note Added: 0001688 | |
| 2013-09-06 04:53 | ajosey | Interp Status | Pending => Proposed |
| 2013-09-06 04:53 | ajosey | Note Added: 0001803 | |
| 2013-10-14 13:08 | ajosey | Interp Status | Proposed => Approved |
| 2013-10-14 13:08 | ajosey | Note Added: 0001897 | |
| 2019-06-10 08:55 | agadmin | Status | Interpretation Required => Closed |
