From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-07-10 14:51:43
On Jul 9, 2004, at 9:47 PM, Matt Hurd wrote:
> From memory the use case was reading stuff and then if that said I
> needed to write something, write it by upgrading the lock.
> However, you are not going to be able to escape the deadlock in this
> case _ever_. AFAICT was if two things read concurrently and need to
> change state, the both can't if the states are dependent and thus you
> always have a deadlock.
The upgradable_read_lock, not abused as in the case I showed, will not
deadlock. The key (and the restriction) is that only one
upgradable_read_lock can be active at a time, though it can share with
any number of read_lock's. You are right about the 2-read-to-write
promotion case. And that is exactly why upgradable_read_lock's are
exclusive among themselves. And it is also why you can't "trick" a
read_lock into a promotion (as my abuse-example showed).
I believe the upgradable_read_lock is still a viable solution for a
very special situation, but it requires suitable documentation to guide
the programmer in how not to abuse it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk