Re: [boost] Lock unification (shared vs. upgradable)

10 Aug 2004

      On Aug 9, 2004, at 7:08 PM, Howard Hinnant wrote:
...
Ok, but what if you do the opposite:
typedef scoped_lock<rw_mutex>     WriteLock;
typedef upgradable_lock<rw_mutex> ReadLock;
WriteLock write_lock(m);
...
if (...)
{
    ReadLock read_lock(m, defer_lock);
    transfer_lock<ReadLock, WriteLock> lock(read_lock, write_lock);
    //  here m is downgraded from write to read
    ...
    //  m is upgraded from read to write before exiting scope
}
// here m is write locked, whether or not if-branch was taken
...
After playing with this some more I've realized that transfer_lock 
simply doesn't work like this in the context of the proposed |= and <<= 
operators.  When transferring ownership from upgradable to scoped, a 
generic utility such as the above will use (pseudo code):

For "lock":
     scoped_lock |= upgradable_lock
For "try lock":
     scoped_lock <<= upgradable_lock
For "unlock":
     upgradable_lock = scoped_lock

If you reverse the roles, it simply will not compile:

For "lock":
     upgradable_lock |= scoped_lock  // no such operation
For "try lock":
     upgradable_lock <<= scoped_lock  // no such operation
For "unlock":
     scoped_lock = upgradable_lock  // no such operation

Therefore transfer_lock is really better named promote_lock.  And if 
you wanted a generic demote_lock then that would probably look like:

For "lock":
     upgradable_lock = scoped_lock
For "try lock":
     upgradable_lock = scoped_lock
For "unlock":
     scoped_lock |= upgradable_lock

And it would be ill-advised to try to couple a demote_lock with another 
lock via a generic "lock 2" algorithm.  Such a generic algorithm could 
probably be set up to detect demote_lock at compile time and refuse to 
compile it.

-Howard