Boost logo

Boost :

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-07 11:37:03


Howard Hinnant wrote:

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

It would be a normal occurrence, but not necessarily because of
concurrent reads. It would be easy for promotion from read-lock to
write-lock to a) prevent any new read or write locks, b) wait until all
current read-locks are released, and then c) obtain the write lock. The
only time a promotion request needs to fail is when multiple threads
request promotion simultaneously; all but one must fail and relinquish
its read lock to prevent deadlock.

Other than that, I agree with everything you've said. (Actually,
re-reading what you've said below, I think maybe that's actually what
you meant anyway).

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

True. The only advantage I can see is in cases where you have many
readers that have to read in order to see if they need write access, and
only few of them ever actually need it. The many checks can happen
simultaneously, and the time saved by the concurrency outweighs the cost
of the few re-reads.

Having said that, I'm not at all tied to that type of scheme. I've
thought all along that lock demotion is more important than lock
promotion (at least for my typical uses of a read/write lock).

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

All this makes sense to me. Again, I like the upgradeable lock agree
that the that it's cleaner and easier to use.

Mike


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk