Порядок вызовов asyncio.Event.set() гарантированно соответствует порядку пробуждения висящих на них корутин?

Question

[wawa]

Подробнее:
Есть n asyncio.Event, на каждом из них висит ровно одна корутина (await asyncio.Event.wait()).
Метод asyncio.Event.set() - не корутина, и его вызов сразу же не отдает управление разбуженной корутине.
Вопрос: если я в цикле вызову на всех ивентах set(), то разбуженные корутины гарантированно начнут работу в том же порядке, в каком я вызвал set() на соответсвтующем ивенте?
Вот пример:

import asyncio


async def coro(n, event):
    await event.wait()
    print(n)


async def main():
    events = []
    for i in range(10):
        event = asyncio.Event()
        events.append(event)
        asyncio.create_task(coro(i, event))

    await asyncio.sleep(2)

    for ev in events[5:] + events[:5]:   # (1) 
        ev.set()

    print('all events are set')

    await asyncio.sleep(2)  # да, я знаю, что не так нужно дожидаться завершения корутин 


if __name__ == '__main__':
    asyncio.run(main())

В строке (1) намеренно изменен порядок вызовов set() и в итоге я получаю в stdout такой порядок чисел: (5,6,7,8,9,0,1,2,3,4), который полностью соответствует порядку вызовов set().
Хотя я запускал этот код не один раз и получал один и тот же результат, все же хочется быть уверенным на 100%, т.е. иметь пруфы, т.к. в моем проекте это важно. Может кто знает где это поведение описывается?

Answer 1

[Владимир Олохтонов]

А как порядок может быть другим? У вас же кооперативная многозадачность.

1) Вы в цикле насоздавали тасков, каждый из которых - это легковесный тред под управлением планировщика asyncio, каждый из них при запуске отдаёт управление обратно планировщику, добавляясь в список на оповещение по event.
2) Потом вы отдали управление планировщику на 2 секунды (зачем?)
3) Вы в фиксированном порядке вызываете ev.set(), что приводит к точно такому-же фиксированному порядку оповещения подписчиков.

Вообще такие штуки надо смотреть в коде, только там можно узнать правду :)

def set(self):
    """Set the internal flag to true. All coroutines waiting for it to
    become true are awakened. Coroutine that call wait() once the flag is
    true will not block at all.
    """
    if not self._value:
        self._value = True

        for fut in self._waiters:
            if not fut.done():
                fut.set_result(True)

@coroutine
def wait(self):
    """Block until the internal flag is true.

    If the internal flag is true on entry, return True
    immediately.  Otherwise, block until another coroutine calls
    set() to set the flag to true, then return True.
    """
    if self._value:
        return True

    fut = self._loop.create_future()
    self._waiters.append(fut)
    try:
        yield from fut
        return True
    finally:
        self._waiters.remove(fut)

Comments

[wawa]

Владимир Олохтонов, спасибо.
(2) - это что-то вроде заглушки, имитирующей вызов какой-то другой await-операции. Сильно обращать на это внимание не стоит.

Вы в фиксированном порядке вызываете ev.set(), что приводит к точно такому-же фиксированному порядку оповещения подписчиков.

Да, в фиксированном порядке я устанавливаю флаг пробуждения. Но обязательно ли этот порядок сохраниться относительно самого пробуждения корутин? Иными словами обладает ли планировщик внутренней очередью, в которую попадает корутина после соответствующего ей ev.set()? Ведь технически эта очередь может отсутствовать. Хоть я и устанавливаю флаги пробуждения в фиксированном порядке, делаю я это строго выполняя только синхронные операции, не отдавая планировщику управление пока не пройдусь по всем ивентам. В итоге на момент передачи управления (второй вызов asyncio.sleep(2)), все корутины готовы выполняться и планировщик может запустить их в рандомном порядке, если только он (планировщик) не обладает внутренней очередью. Поэтому мой вопрос к этому и сводится: есть ли у него эта самая очередь? И насчет кода, вы абсолютно правы, но я не смог обнаружить эту очередь - сложновато для меня. Может у вас получится?
Еще раз попробую немного переделать вопрос (наверно сумбурно изъясняюсь, ибо сложная для меня тема): непосредственно вызов ev.set() помещает ли соответствующую корутину (ждущую на этом Event) в предполагаемую мной очередь планировщика, тем самым гарантируя, что эта корутина продолжит своё выполнение раньше тех корутин, чьи ev.set() были вызваны позже и позже тех корутин, чьи ev.set() были вызваны раньше?

[Владимир Олохтонов]

wawa,

непосредственно вызов ev.set() помещает ли соответствующую корутину (ждущую на этом Event) в предполагаемую мной очередь планировщика, тем самым гарантируя, что эта корутина продолжит своё выполнение раньше тех корутин, чьи ev.set() были вызваны позже и позже тех корутин, чьи ev.set() были вызваны раньше?

Гарантии порядка запуска планировщик вам не даёт, более того, существуют разные реализации политик event-loop'а, которые запускают задачи в разном порядке. Если вам нужна упорядоченность между независимыми задачами - используйте примитивы синхронизации (блокировки), синхронный код или треды, которыми гораздо легче управлять.

В PEP 3156 сказано, что планировщика в явном виде не существует, на самом деле он реализован в коде классов Feature и Task, вот что удалось найти в коде Feature:

def cancel(self):
        """Cancel the future and schedule callbacks.

        If the future is already done or cancelled, return False.  Otherwise,
        change the future's state to cancelled, schedule the callbacks and
        return True.
        """
        self._log_traceback = False
        if self._state != _PENDING:
            return False
        self._state = _CANCELLED
        self._schedule_callbacks()
        return True

    def _schedule_callbacks(self):
        """Internal: Ask the event loop to call all callbacks.

        The callbacks are scheduled to be called as soon as possible. Also
        clears the callback list.
        """
        callbacks = self._callbacks[:]
        if not callbacks:
            return

        self._callbacks[:] = []
        for callback in callbacks:
            self._loop.call_soon(callback, self)

То есть когда задача завершается, она дергает все подписанные на неё коллбеки, в том порядке, в котором они были объвлены. Но рассчитывать на это не стоит, лучше писать код, который не зависит от реализации планировщика.

[Владимир Олохтонов]

Вообще я рекомендую не использовать асинхронность, если это возможно в вашем случае, вы этим здорово упростите жизнь себе и окружающим, вот замечательный текст на эту тему от автора фреймворка curio:
https://curio.readthedocs.io/en/latest/devel.html#...

[Taus]

Владимир Олохтонов, 2) на самом деле достаточно await asyncio.sleep(0), но если не передать контекст EventLoop, то выполнится весь код дальше и будут установлены Event. А когда контекст получат таски, то поскольку все Event установлены, то они выполняться в том порядке как определит планировщик. В случае стандартных планировщиков - в порядке создания, на данный момент.

[Владимир Олохтонов]

Taus, я конечно не специалист по асинхронщине на питоне, но неявное управление планировщиком, на мой взгляд, плохо пахнет.