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
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:
> (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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk