Re: Are PRRWLock read locks reentrant?

On Mon, Oct 12, 2009 at 2:01 PM, Nathan Kinder <[email protected]> wrote:
>
> Sorry to bring up such an old message thread, but an issue has come up
> related
> to re-entrant use of PR_RWLock_Rlock().
>
> The way PR_RWLock works is that a waiting writer will block any threads
> attempting to get a new read lock.  If you use read locks in a re-entrant
> manor, a request for a write lock between the two read lock calls will cause
> a
> deadlock (the writer is waiting for the reader to exit, and the reader can't
> get the re-entrant lock since the writer is waiting).  I am running into
> this
> deadlock in my application.
>
> I'd like to propose that we modify PR_RWLock to behave differently when a
> re-entrant read lock is made.  If a thread already holds a read lock and
> tries
> to get another readlock, this should be allowed, even if a writer is waiting
> on
> the write lock.  Any other threads attempting to get a read lock will have
> to
> wait on the writer since it is given priority.  This approach would prevent
> the
> writer from being starved due to many active readers, yet it would also
> allow
> for safe re-entrant use of read locks without chance of a deadlock.
>
> Does the above proposal sound feasible?

Hi Nathan,

We have three implementations of PRRWLock.
Two of them (HAVE_UNIX98_RWLOCK and HAVE_UI_RWLOCK)
are based on native thread libraries. Unless the behavior you
proposed is documented in the Unix 98 reader-writer locks,
if we make this change, we won't be able to use Unix 98
reader-writer locks.

It seems that native thread libraries must solve this problem
if they allow a thread to hold multiple concurrent read locks,
and it seems that your proposal is the obvious solution.
I'm worried that native thread libraries actually implement
your solution but fail to document it.

Wan-Teh