Re: Are PRRWLock read locks reentrant?

On 10/12/2009 04:32 PM, Wan-Teh Chang wrote:
> 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.

If this is the case, how can we move forward on fixing this issue?  Is 
there anything I can do to help?

There is no easy way for me to change my application to avoid re-entrant
use of read locks unfortunately.

-NGK

>
> Wan-Teh