[Async-sig] question re: asyncio.Condition lock acquisition order

[Chris Jerdonek]

On Tue, Jun 27, 2017 at 3:48 PM, Nathaniel Smith <njs at 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