On Tue, 6 Jul 2004 03:29:15 +0000 (UTC), Matthew Vogt <mvogt@juptech.com> wrote:
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 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?
Yes.
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. 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