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