On Sat, 10 Jul 2004 15:51:43 -0400, Howard Hinnant <hinnant@twcny.rr.com> wrote:
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.
OK. I buy that, but perhaps as a separate mutex beyound the standared shareable (rw). I suspect some platforms will support rw_mutex like behaviour natively without the upradeable part. The upgradeable shareable lock would work if only one is allowed and it had priority over blocking exclusive locks to prevent state invalidation. It would have to be a special situation where the section of code was not in high contention due to its lack of concurrency (which would be the same for an exclusive lock), with reasonable read concurrency benefits from other sections of code and lowish probability ( at least less than 100% ;-) ) that an upgrade to exclusive (write) access should take place. Does that sound right? I'm not sure I have that correct. Struggling for a use case myself, but it doesn't sound improbable. Perhaps taking a upgradeable read lock or write lock when the thread already has a read, or a write lock when the thread has an upgradeable read lock, should generate an exception, at least in debug mode in addition to the documentation. I think rw_mutex already does this for the read to write from memory. Regards, Matt Hurd.