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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
