This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: pthread_rwlock and writers preference
- From: Rich Felker <dalias at aerifal dot cx>
- To: chrubis at suse dot cz
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 10 Jul 2013 21:22:17 -0400
- Subject: Re: pthread_rwlock and writers preference
- References: <20130710160041 dot GA20255 at rei dot Home>
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