On Tue, Jun 27, 2017 at 3:48 PM, Nathaniel Smith <n...@pobox.com> 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. --Chris _______________________________________________ Async-sig mailing list Async-sig@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/
