Are PRRWLock read locks reentrant?
Nathan Kinder
PRRWLock using PR_RWLock_Rlock() reentrant?
-NGK
Wan-Teh Chang
> I know that a PRLock is not reentrant, but is getting a read lock on a
> PRRWLock using PR_RWLock_Rlock() reentrant?
I checked the implementation. The answer is Yes, it is reentrant.
This is reasonable because a reader-writer lock allows multiple
readers, including a reader acquiring it multiple times. See also
the pthread_rwlock_rdlock man page at
http://opengroup.org/onlinepubs/007908799/xsh/pthread_rwlock_rdlock.html
which says:
A thread may hold multiple concurrent read locks on rwlock (that is,
successfully call the pthread_rwlock_rdlock() function n times). If so,
the thread must perform matching unlocks (that is, it must call the
pthread_rwlock_unlock() function n times).
Wan-Teh
Nathan Kinder
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 ad eadlock (the writer is waiting for the reader to
exit, and the reader can'tget 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 read lock, 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?
Thanks,
-NGK
Wan-Teh Chang
>
> 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
> 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
> 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
Nathan Kinder
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