This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/13701] pthread_rwlock_rdlock & realtime scheduling writer lock precedence

Bruno Haible <bruno at clisp dot org> changed:

           What    |Removed                     |Added
                 CC|                            |bruno at clisp dot org

--- Comment #4 from Bruno Haible <bruno at clisp dot org> ---
There is also a second test case from the Linux test project, This one
considers readers and writers that have the same assigned priority:

$ wget
$ wget
$ gcc -O -Wall 2-2.c -lpthread
$ ./a.out 
main: attempt read lock
main: acquired read lock
main: create wr_thread, with priority: 2
wr_thread: attempt write lock
main: create rd_thread, with priority: 2
rd_thread: attempt read lock
rd_thread: acquired read lock
rd_thread: unlock read lock
Test FAILED: rd_thread did not block on read lock, when a reader owns the lock,
and an equal priority writer is waiting for the lock

Re comment 3:
> if Thread Execution Scheduling is supported (and glibc claims it is)
Yes. The symbol _POSIX_THREAD_PRIORITY_SCHEDULING is defined by glibc. It is
actually defined in <bits/posix_opt.h> with a comment:

/* We provide priority scheduling for threads.  */

The value is a positive constant.
Per and this
means that glibc supports the Thread Priority Scheduling option of POSIX at
compile time and at run time.

The test activates the SCHED_FIFO on all of its threads. Therefore the premises
of the sentence "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." from
are fulfilled. And the writer and readers in this test case have equal

> Implementing the special requirements for Thread Execution Scheduling seems difficult, especially in an efficient way
Implementing the handling of readers and writers of different priority (test
case 2-1.c) is some work, indeed. But the handling of readers and writers of
equal priority is nearly complete in glibc: The non-portable flag
pthread_rwlock_init and pthread_rwlockattr_init would have to be changed.

rwlocks without the "writers get the rwlock in preference to readers [of the
same priority]" guarantee are quite unreliable (no way to guarantee that
writers will not get starve, except if there's only 1 reader thread - but then
one can just use a normal mutex as well), I'm arguing in

You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]