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

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-08-04 20:06:43

On Aug 4, 2004, at 4:45 PM, Bronek Kozicki wrote:

> Is there any reason for distinction between shared lock and upgradable 
> shared lock? I mean - obviously updgradable shared lock can be 
> upgraded to exclusive one, but do we need separate type for this? 
> What's rationale behind this distinciton? I can easily imagine design 
> (and implementation) where every shared lock is also upgradable one, 
> if it's mutex type support upgrade operation. Under such design one 
> can upgrade shared lock only if it's the only (currently locking) lock 
> on synchromization object (supporting such transition). Implementation 
> of such mutex could be very similar to semaphore (or just using 
> semaphore, if present on platform).

The advantage of the separate upgradable_lock type is that when an 
upgradable_lock transfers ownership to a scoped_lock, then the thread 
can assume that what was read while holding upgradable ownership is 
still valid (does not need to be re-read, re-computed) while holding 
the scoped_lock.  This is true even if the thread had to block while 
transferring mutex ownership from the upgradable_lock to the 
scoped_lock.

If sharable_lock can transfer mutex ownership to scoped_lock, then the 
thread can no longer make this assumption.  If the thread blocks for 
this ownership transfer, it is possible that another thread will 
interrupt, upgrade a sharable_lock, and write.  The original thread, 
upon obtaining the scoped_lock, is forced to re-read or re-compute its 
data upon obtaining the scoped_lock ownership because of this 
possibility.  Thus it might as well just have relinquished shared 
ownership and blocked for exclusive ownership.

Having said that, it is true that we could add:

bool try_unlock_sharable_and_lock();

to the mutex functionality.

This would mean adding the following to scoped_lock:

     scoped_lock(rvalue_ref<sharable_lock<mutex_type> > r, 
detail::try_lock_type);
     scoped_lock& operator<<=(rvalue_ref< sharable_lock<mutex_type> > r);

Meaning, you could try to upgrade a sharable_lock to a scoped_lock, but 
there would be no way to force the upgrade.  It adds an unsymmetric 
aspect to the interface:  every other try-function has a corresponding 
blocking function.

Aside from the asymmetry, I also wonder about the practicality of such 
an operation.  A shared_lock context is usually set up because one 
anticipates common simultaneous non-destructive locking.  If 
simultaneous non-destructive locking is rare, there is no advantage 
over exclusive locking.  So if simultaneous non-destructive locking is 
common, that means a successful call to try_unlock_sharable_and_lock() 
will be rare (and if it isn't, then a simple exclusive mutex would have 
probably been a better design).  It occurs to me that offering such an 
interface might be encouraging an interface that blocks a thread 
indefinitely (just keeps trying).  Whereas if the code had just 
relinquished shared ownership and blocked for exclusive, then the mutex 
design is likely to already be set up to not starve writers.

-Howard