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

From: Bruno Martínez Aguerre (br1_at_[hidden])
Date: 2004-07-06 00:02:44

On Tue, 6 Jul 2004 03:29:15 +0000 (UTC), Matthew Vogt <mvogt_at_[hidden]>  
wrote:

> Bruno Martínez Aguerre <br1 <at> internet.com.uy> writes:
>
>> What about a latent_write_lock?
>>
>> It's semantics would be to block on construction until it only shares  
>> the
>> mutex with read_locks.  A write_lock could be constructed from a
>> latent_write_lock and this would always work, because another
>> latent_write_lock would still be blocked in it's constructor.  This kind
>> of lock would be useful for situations in which you have to read a
>> structure to know if you have to write on it.
>
> Interesting, this divides read locks into promotable and non-promotable
> variants?

Yes.

> If you have a design where a lot of threads take concurrent read locks, 
> and the case of promotion is rare, then having them all use 
> latent_write_locks will unnecessarily serialise them.  Allowing  
> promotion failure instead would only
> affect rare cases of promotion contention.

That's true.  If promotion is uncommon, the best solution would be to  
unlock the read_lock and construct a normal write_lock.  It's a rare  
situation, and the code is simpler this way than dealing with  
exceptions/retries.

> If you have a case where promotion is common, then you probably won't  
> gain much over simply using write locks, will you?

If promotion is common and the reading part is long, a latent_write_lock  
would be better than a write_lock because it wouldn't block normal readers  
until necesary.  Trying to promote a read_lock and failing would be more  
expensive because the reading would have to be done again.

> If you can mix a number of read-only locks with a small number of
> latent_write_locks for which promotion is uncommon, then you have an  
> optimum result.

I'll have to think about this last sentence a little more.

Bruno Martinez