On Wed, 7 Jul 2004 11:10:22 -0400, Howard Hinnant <hinnant@twcny.rr.com> wrote:
I've been giving the fail-able read promotion more thought...
The purpose of using read/write locks is presumably to allow concurrent reads. In such a design, concurrent reads are probably expected as the norm, else the cheaper and simpler scoped_lock is likely to be more appropriate. Given that concurrent reads are likely to be a normal occurrence, it follows that a failed read_lock promotion would also be a normal occurrence. In the event of a failed read_lock promotion, the typical strategy is to accept that you have to block for write access, and to reread (or recompute) whatever you obtained under the read lock.
I think it is better to see this third kind of lock as a write lock instead of as a read lock. IMHO, it doesn't follow from concurrent reads being a normal occurrence that a failed read_lock promotion would also be a normal occurrence. If promotion isn't available in any way, you wouldn't have a choice but to use write_lock. A write_lock blocks for two reasons: 1) it has to wait it's turn to be the only writer, and 2) it has to wait until no more readers remain. A latent_write_lock gives you the oportunity to do work while only 1) has been achieved; later you can apply for 2). Seeing it this way, there's a progression in optimization from ScopedLock, read_lock - write_lock and read_lock - latent_write_lock - write_lock. Note I think failable promotion could be useful even having latent_write_lock. Bruno Martinez