Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000722 [1003.1(2013)/Issue7+TC1] Base Definitions and Headers Editorial Clarification Requested 2013-07-15 15:52 2019-06-10 08:55
Reporter chrubis View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
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 Note: 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

While the pthread_rwlock_wrlock says:

Implementations may favor writers over readers to avoid writer

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] [^]

[2] [^]
Desired Action Clarification whether write preference is required and if so under which conditions.
Tags tc2-2008
Attached Files

- Relationships
related to 0000720Closedajosey 1003.1(2008)/Issue 7 Can pthread_rwlock_wrlock be called recursively by the same thread? 

-  Notes
msbrown (manager)
2013-07-18 16:09
edited on: 2013-07-18 16:12

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.

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.

jilles (reporter)
2013-07-18 22:11

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.
geoffclare (manager)
2013-07-19 08:59

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.
ajosey (manager)
2013-09-06 04:53

Interpretation Proposed 6 Sep 2013
ajosey (manager)
2013-10-14 13:08

Interpretation approved 14 October 2013

- Issue History
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 => Note: 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

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker