Re: pthread_rwlock and writers preference

[chrubis at suse dot cz]

Hi!
> > Some time ago I've reported a bug 13701 as there are posix tests in LTP
> > that are failing with glibc. Now after carefully reading the
> > corresponding specification I'm not sure whether it's really a glibc bug.
> > 
> > The pthread_rwlock_rdlock[1] 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.
> 
> This is almost surely a mistake, since just below, it is specified
> that you can use recursive read locks:
> 
>     A thread may hold multiple concurrent read locks on rwlock (that
>     is, successfully call the pthread_rwlock_rdlock() function n
>     times). If so, the application shall ensure that the thread
>     performs matching unlocks (that is, it calls the
>     pthread_rwlock_unlock() function n times).
> 
> Obviously this would lead to permanent deadlock if there is a writer
> waiting and rdlock cannot succeed while a writer is waiting. It's
> possible that EDEADLK could be returned in this case, but EDEADLK is
> specified as a "may fail", not a "shall fail".
> 
> Note that there is no way for the implementation to identify whether
> the caller of rdlock already holds a read lock on the referenced
> rwlock object without unbounded storage, so it is not reasonable to
> interpret the requirements as allowing recursive rdlock while a writer
> is waiting but forbidding new readers from arriving.
> 
> I think the requirements here are just fundamentally conflicting, and
> the only reasonable solution I see is weakening the preference for
> writers.

Ah it's even a little more complicated. The testcase in question [1]
combines the rwlock with TPS and for that case the pthread_rwlock_rdlock
specification says:

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.

But that only narrows down number of cases where writers should be
preferred to threads with higher or equal priority.

> This should be discussed on the Austin Group list and/or tracker.

I've created an account in the Austin Group tracker but the new report
page requires Page Number and Line Number and these are not available in
the html version of the standard.

[1] http://ltp.git.sourceforge.net/git/gitweb.cgi?p=ltp/ltp.git;a=blob;f=testcases/open_posix_testsuite/conformance/interfaces/pthread_rwlock_rdlock/2-1.c

-- 
Cyril Hrubis
chrubis@suse.cz