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

From: Bronek Kozicki (brok_at_[hidden])
Date: 2004-08-05 08:17:08

Howard Hinnant wrote:
> 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 we give this ability to shared_lock, would there be still need for
separate class upgradable_lock? Or in other words : does upgradable_lock
have any ability that is conflicting with abilities that we need in
shared_lock, so that we may not put all these abilities in one class and
drop the other one? I cannot see such conflict right now, which make me
wonder why we need two classes (shared_lock and upgradable_lock) at all?

> 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.

I do not see conflict here, ie. if we give shared_lock ability to
upgrade with warranty that lock has not been released during operation
(atomic operation, possibly blocking, and/or non-blocking "try"
operation), operation you mention above would still be doable as simple
release shared lock and then acquire exclusive lock (non-atomic). As you
noticed in last (cited above) sentence.

B.