Boost logo

Boost :

From: Bruno Martínez Aguerre (br1_at_[hidden])
Date: 2004-07-08 09:42:40

On Wed, 7 Jul 2004 11:10:22 -0400, Howard Hinnant <hinnant_at_[hidden]>

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

Note I think failable promotion could be useful even having

Bruno Martinez

Boost list run by bdawes at, gregod at, cpdaniel at, john at