From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2006-10-24 12:12:04
"Chris Thomasson" <cristom_at_[hidden]> writes:
> "Anthony Williams" <anthony_w.geo_at_[hidden]> wrote in message
>> The way I see it, the ideal is that a waiting writer will block any fresh
>> readers until all the current readers have gone away, but once that
>> and the lock is released, the waiting writer and the waiting readers will
>> compete equally.
> Well, IMHO:
> A rw-mutex usually makes readers block/wait for all "prior writes" and the
> "last write broadcasts". A write usually blocks/waits for all "prior
> reads/writes", and the "last read signals/last write broadcasts"...
> Anyway, I believe that it is sufficient to prevent the starvation of writers
> because a high number of readers is simply implied wrt rw-mutexs... So, it
> naturally seems that writes would be the only thing that could get subjected
> to any kind of starvation...
> Again, if your rw-mutex is getting hit with enough writes to even begin to
> start to starve the readers, then the user of the rw-mutex is using it
> improperly... IMHO of course...
I agree that preventing writers starving should be sufficient in most cases. I
just happen to think that it's less than ideal.
I was imagining a system with several hundred readers, and a couple of
writers. If the writers take sufficiently long, you might find that you have
one waiting on the other. The readers then get starved if you give writers
priority, just as the writers get starved if you give readers priority.
If, when the first writer unlocks, the readers compete with the waiting
writer, then most of the time some readers will get in before the writer
re-registers that it's waiting, and blocks the rest. You could just unblock
one thread, and if it's a reader then it unblocks all currently-waiting
readers. Rather like a condition variable broadcast....
-- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk