Can a thread write-lock a rwlock that it already has read-locked?

[David Barrett <db...@quinthar.com>]

I'm experimenting with the reader/writer locks and have a question:

	Can a thread write-lock a thread on which it already holds the read
lock?

My tests seem to indicate that this is not allowed, but I want to confirm
this is by design and not something I'm just doing wrong.  Specifically, I'm
using the following code:

# apr_pool_t* pool;
# apr_pool_create( &pool, 0 );
# apr_thread_rwlock_t* lock;
# apr_thread_rwlock_create( &lock, pool );
# apr_thread_rwlock_rdlock( lock );
# apr_thread_rwlock_wrlock( lock ); // Hangs on this line
# apr_thread_rwlock_unlock( lock );

Is this working as designed?  I'm running this test on Win32.

My followup question is, is there any way to override this behavior?  It
would seem to me that a thread could safely hold both a read and write lock,
so long as no other thread held either.  Furthermore, it'd be nice to give
up the write lock without giving up the read lock.  The pattern I'd like to
use is something like:

# get read lock
#    do some tests to decide if I need to write anything
#       get the write lock
#          make some changes
#       give up the write lock
#    do some more stuff just with the read lock
# give up the read lock

Is there something fundamentally wrong with this pattern that I'm not
seeing?  Is there some compelling reason why the "rwlock" must disallow a
thread from holding both a read and write lock?

-david