Boost logo

Boost :

From: Bruno Martínez Aguerre (br1_at_[hidden])
Date: 2004-07-06 00:02:44

On Tue, 6 Jul 2004 03:29:15 +0000 (UTC), Matthew Vogt <mvogt_at_[hidden]>

> 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, this divides read locks into promotable and non-promotable
> 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

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

Bruno Martinez

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