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> internet.com.uy> writes:
>> What about a latent_write_lock?
>> It's semantics would be to block on construction until it only shares
>> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk