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

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-07 10:57:51

Howard Hinnant <hinnant_at_[hidden]> writes:

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

If that's so, I'd have to say that an exception is a very poor choice
for reporting failure to acquire the lock.  I don't know whether
that's still under consideration...

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com