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

["bruno at clisp dot org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=13701

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
https://raw.githubusercontent.com/linux-test-project/ltp/master/testcases/open_posix_testsuite/conformance/interfaces/pthread_rwlock_rdlock/2-2.c
$ wget
https://raw.githubusercontent.com/linux-test-project/ltp/master/testcases/open_posix_testsuite/include/posixtest.h
$ 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.  */
#define _POSIX_THREAD_PRIORITY_SCHEDULING       200809L

The value is a positive constant.
Per http://pubs.opengroup.org/onlinepubs/007904875/basedefs/xbd_chap02.html and
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html 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
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_rdlock.html
are fulfilled. And the writer and readers in this test case have equal
priority.

> 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_PREFER_WRITER_NONRECURSIVE_NP does it. Only the functions
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
http://lists.gnu.org/archive/html/bug-gnulib/2017-01/msg00037.html

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