Boost logo

Boost :

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at