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