On Tue, Jun 27, 2017 at 3:48 PM, Nathaniel Smith firstname.lastname@example.org wrote:
On Tue, Jun 27, 2017 at 4:15 AM, Chris Jerdonek
Thinking through the requirements I want for my RW synchronization use case in more detail, I think I want the completion of any "write" to be followed by exhausting all "reads." I'm not sure if that qualifies as barging. Hopefully this will be implementable easily enough with the available primitives, given what you say.
I've only seen the term "barging" used in discussions of regular locks, though I'm not an expert, just someone with eclectic reading habits. But RWLocks have some extra subtleties that "barging" vs "non-barging" don't really capture. Say you have the following sequence:
task w0 acquires for write task r1 attempts to acquire for read (and blocks) task r2 attempts to acquire for read (and blocks) task w1 attempts to acquire for write (and blocks) task r3 attempts to acquire for read (and blocks) task w0 releases the write lock task r4 attempts to acquire for read
What happens? If r1+r2+r3+r4 are able to take the lock, then you're "read-biased" (which is essentially the same as barging for readers, but it can be extra dangerous for RWLocks, because if you have a heavy read load it's very easy for readers to starve writers).
All really interesting and informative again. Thank you, Nathaniel. Regarding the above, in my case the "writes" will be a background cleanup task that can happen as time is available. So it will be okay if it is starved.