[boost] rw_lock / next thread version

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2003-07-13 18:04:57

I'm not positive if a read/write lock is being contemplated for a 
future boost::threads version or not.  But I was stumbling through 
thread_dev and came upon a rw_mutex which might be used something like:

class A
{
public:
     ...
     void read() const
     {
         boost::rw_mutex::scoped_rw_lock lock(mut_);
         ...
     }

     void write()
     {
         boost::rw_mutex::scoped_rw_lock lock(mut_, boost::EXCL_LOCK);
         ...
     }
     ...
private:
     ...
     mutable boost::rw_mutex mut_;
};

And if you needed to "manually" lock the scoped_rw_lock, it would look 
like:

lock.rdlock();

or

lock.wrlock();

Unlocking a scoped_rw_lock follows the more familiar:

lock.unlock();

which then figures out at run time whether it is unlocking a reader or 
a writer.

Ok, enough of the review.  Assuming that rw_lock is destined for 
release, I propose that whether you want to lock for reading, or for 
writing, is usually a decision made at compile time, and that this fact 
can be made to slightly simplify the scoped_lock interface, and make it 
slightly more efficient.  So as a minor twist to the interface, I 
propose:

class rw_mutex
{
public:
             typedef detail::read_lock<rw_mutex>  read_lock;
        typedef detail::write_lock<rw_mutex> write_lock;
      ...
};

I'm not picky about the names read_lock and write_lock.  Then these 
locks could have the "standard" scoped_lock interface.  So the "A" 
example above would look more like:

class A
{
public:
     ...
     void read() const
     {
         boost::rw_mutex::read_lock lock(mut_);
         ...
     }

     void write()
     {
         boost::rw_mutex::write_lock lock(mut_);
         ...
     }
     ...
private:
     ...
     mutable boost::rw_mutex mut_;
};

And if you needed to lock these manually, then you could say:

lock.lock();

instead of

lock.rdlock() or lock.wrlock();

This looks slightly more readable and writable to me.  And will avoid 
unlock() having to check what kind of lock (read or write) it is trying 
to unlock.

-Howard