Re: pthread_rwlock and writers preference

[Rich Felker <dalias at aerifal dot cx>]

On Wed, Jul 10, 2013 at 06:00:41PM +0200, chrubis@suse.cz wrote:
> 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.

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

Rich