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

[Chris Jerdonek]

On Tue, Jun 27, 2017 at 3:29 AM, Nathaniel Smith <njs at pobox.com> wrote:
> In fact asyncio.Lock's implementation is careful to maintain strict
> FIFO fairness, i.e. whoever calls acquire() first is guaranteed to get
> the lock first. Whether this is something you feel you can depend on
> I'll leave to your conscience :-). Though the docs do say "only one
> coroutine proceeds when a release() call resets the state to unlocked;
> first coroutine which is blocked in acquire() is being processed",
> which I think might be intended to say that they're FIFO-fair?
> ...

Thanks. All that is really interesting, especially the issue you
linked to in the Trio docs re: fairness:
https://github.com/python-trio/trio/issues/54

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.

Can anything similar be said not about synchronization primitives, but
about awakening coroutines in general? Do event loops maintain strict
FIFO queues when it comes to deciding which awaiting coroutine to
awaken? (I hope that question makes sense!)

--Chris