[boost] Re: Boost.Threads: Do we need all those mutexes?

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