Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-07-04 16:25:27

On Jun 29, 2004, at 12:30 PM, Michael Glassford wrote:

> Also, you could end up with some interesting situations like this:
> void f(read_write_mutex m)
> {
> read_write_mutex::read_lock r(m);
> if (...)
> {
> read_write_mutex::write_lock w(r); //lock promotion
> //...
> }
> //Point A
> }

How 'bout:

     void f(read_write_mutex& m)
         read_write_mutex::read_lock r(m);
         if (...)
             read_write_mutex::write_lock w(m);
             //... m is write locked
         //Point A ... m is read locked

Transferring mutex ownership from a read_lock to a write_lock is always
a blocking operation. So there's no advantage to a
transfer_to_write_lock() function. You might as well manually unlock
the read_lock and manually lock the write_lock as shown above. But the
write_lock::transfer_to_read_lock() member can atomically transfer
ownership to the appointed read_lock and notify all other read_lock's
that it is time to wake up.


1. There's only two types of locks: read_lock, write_lock.
2. Exception safety is maintained.
3. Interface is minimal and intuitive (at least to me).
4. r is always locked at Point A.
5. If the write_lock branch is taken, the code can assume that at
Point A the thread is reading what was written while the write_lock was
held. There is no chance for another thread to write.
6. There is no chance for deadlock of multiple read_locks waiting for
promotion because there is no such operation. You must unlock the
read_lock and then block for a write_lock.


PS: I find the promotion/demotion terminology confusing.

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