Threads: rw_mutex design + sample implementation

From: dmoore99atwork (dmoore_at_[hidden])
Date: 2002-03-10 16:58:46

I have uploaded design documentation as well as a prototype 
implementation for reader/writers locks to the file library:

http://groups.yahoo.com/group/boost/files/thread_rw_lock.zip

The design allows for a number of scheduling policies between readers 
and writers.  The prototype implementation uses a pair of mutexes and 
a condition variable and derives directly from that used for pthreads-
win32.  The boost::mutex used for internal state mutual exclusion and 
tends to favor a new writer if only readers are currently holding a 
lock.  If readers and writers are waiting, the ordering falls back to 
the ordering of the underlying mutex.

Comments and feedback of any nature are welcome, but I am especially 
interested in hearing other's views on:

1.  Reader "promotion" to writer status w/o releasing the lock.  To 
me, this is only safe when the promotion is treated as a try and 
return, ala boost::try_mutex.  If you let a promotion request block, 
then any other promotion request can lead to deadlock, or complex 
queuing is required.  With the prototype implementation, adding 
promotion to try_rw_mutex is straightforward.  Adding it elsewhere is 
tricky...

2.  Naming of rw_mutex.  Everyone else calls them rw_locks, but that 
seemed to conflict with the scoped_lock family of concepts/classes, 
so I tried to avoid it.   I have no problem renaming it to rw_lock, 
though.

3.  It would be nice to be able to use scoped_lock with rw_mutex, and 
be able to use scoped_rw_lock with mutex....   There are times during 
application design & testing where it is nice to be able to 
experiment with swapping a mutex for a rw_mutex, to see if the 
rw_mutex is truly needed.  It would be nice if scoped_rw_lock<mutex> 
would just lock() the mutex even if a sharedlock() was requested, and 
if scoped_lock<rw_mutex> would always just call lock() on the 
rw_mutex.   It seems that some solution involving lock_ops() is 
possible, but I'd like more input on this.

Dave