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

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-06 09:29:15

Bruno Martínez Aguerre wrote:

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

I think so, too. Given the current implementation of Boost.Threads 
read/write locks, it wouldn't be too difficult to add this, if it was 
determined to be worthwhile. But I wonder how easy it would be to add to 
other implementations? After all, Boost is only partly about providing 
an implementation, but even more about specifying a well-designed, 
widely-implementable interface.

 >> this divides read locks into promotable and non-promotable
>> variants?
> Yes.

Or perhaps into promotable-without-fail and promotable-with-fail variants.

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

Two comments: the more common promotion is, the fewer normal readers 
there will be; and, since all latent readers are serialized, it only 
makes sense to use latent readers if a high percentage of them will end 
up being promoted, even if reading is expensive (in other words, it's a 
tradeoff between how expensive reading is and how expensive 
serialization is).

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

Mike