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.