Boost logo

Boost :

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:

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

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,

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at