Bruno MartÃnez Aguerre wrote:
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,
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.
Mike