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

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2004-08-04 18:04:53

On Wed, 04 Aug 2004 22:45:26 +0200, Bronek Kozicki <brok_at_[hidden]> 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).
> 
<snip>
An upgradeable lock that is sharing reading needs to be an exclusive
upgradeable lock.

There are use cases for it but they are rare due to the conditions to
make the taking of such a lock worthwhile, especially considering its
exclusiveness property and priortization requirements.

The implementation of the mutex would likely need additional state as
well, but that is fairly moot.

Another rationale for keeping it separate would be that shared /
exclusive (r/w) locking and the interface should be minimal to support
exisiting os's, standards, libraries and patterns of use.  It would be
nice to keep this mechanism simple enough to map to alternative
implementations where possible.

So I see two issues, risks of use/overuse and ease of mapping to
existing practice.

Therefore I think it makes sense to keep the upgradeable feature separate.

$0.005

Matt Hurd.