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

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-07-07 10:10:22

On Jul 7, 2004, at 9:26 AM, Michael Glassford wrote:

> However, I don't see any way to avoid re-trying after the write-lock 
> is obtained when promotion fails, and I don't see a way to prevent 
> promotion from failing except for the suggested latent-read-lock / 
> upgradeable-read-lock. I agree that such a lock is a good idea, but it 
> does have the drawback of serializing all upgradeable read locks, 
> which could be quite undesirable in some circumstances.

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.

Given that the expected norm is fail-block-reread, is there any 
advantage to this approach?  That is, in a design where you expect 
multiple concurrent read promotions, they have to be serialized no 
matter what.  In a design where you expect multiple concurrent read 
promotions to be rare the upgradable_read_lock, or even the far simpler 
scoped_lock (in the case concurrent reads are rare) should not incur a 
performance hit.

The big motivation that I see for the upgradable_read_lock is the 
scenario linked to by Alexander yesterday:

On Jul 6, 2004, at 5:02 AM, Alexander Terekhov wrote:

> Read this thread:
>
> http://groups.google.com/groups?threadm=ijnd7a.3pb.ln%40tux.localdomain
> (Subject: upgradeable lock)

If you have multiple long read/compute then write threads, there is no 
other logic that solves the problem other than serialization, no matter 
how it is coded.

The paragraph that David Butenhof wrote in response to the fail-able 
read promotion design (which Alexander also quoted here) summed up (and 
cemented) my thoughts as well.

-Howard