Гарантирует ли asyncio строгую очередность выполнения корутин, готовых к продолжению?
Нет, asyncio не гарантирует строгую очередность выполнения готовых корутин как часть пользовательского контракта. Event loop обычно обрабатывает готовые callbacks и продолжения задач в порядке их постановки в очередь, но этот порядок может меняться из-за таймеров, событий ввода-вывода, отмены и новых callbacks. Поэтому корректность программы нельзя строить на предположении о конкретной очередности.
asyncio создавался для эффективного обслуживания большого числа операций ввода-вывода без выделения отдельного потока под каждую операцию. Такой подход использует один event loop и кооперативную передачу управления: задача сама должна приостановиться на операции ожидания.
Главная цель модели — управляемое планирование большого количества I/O-задач, а не реализация строгого планировщика с гарантиями справедливости или временных квантов. Поэтому порядок запуска продолжений является деталью планирования, а не механизмом синхронизации.
Если разработчик предполагает, что корутины всегда продолжатся в порядке создания, программа может работать случайно: локально задачи будут печатать ожидаемый результат, а под нагрузкой или при другой комбинации таймеров и сетевых событий — другой.
Особенно опасно использовать порядок выполнения для защиты общего состояния, организации очереди запросов или выбора «первой» завершившейся операции. Отсутствие await на продолжительном участке кода создаёт другую проблему: одна корутина блокирует event loop, и остальные вообще не получают управления.
Event loop хранит готовые к выполнению callbacks. Продолжение Task после приостановки также представлено callback, который нужно выполнить в потоке event loop. В типичной реализации asyncio готовые callbacks обрабатываются последовательно; callbacks, добавленные во время текущего прохода, обычно выполняются уже на следующем проходе.
Это объясняет часто наблюдаемое поведение, похожее на FIFO, но FIFO не является гарантией строгой очередности корутин. Одна задача может быть поставлена в очередь после завершения Future, другая — после таймера, третья — после сетевого события. Реальный порядок зависит от момента, когда соответствующее событие стало готово.
await передаёт управление только тогда, когда ожидаемая операция действительно приостанавливает корутину. Если ожидаемый объект уже завершён, выполнение может продолжиться без полезного уступания управления. Поэтому сам факт наличия await не гарантирует переключение на конкретную соседнюю задачу.
Для явной координации применяют asyncio.Queue, asyncio.Event, asyncio.Lock, Future или другой протокол обмена. Эти примитивы выражают требуемое условие напрямую: например, «обработать элемент после его помещения в очередь», а не «надеяться, что другая корутина выполнится первой».
Корутина, выполняющая длительный синхронный или CPU-bound участок без приостановки, может полностью задержать остальные задачи. Для такой работы используют вынос в поток или процесс, но выбор исполнителя зависит от характера нагрузки: поток обычно помогает не блокировать event loop при ожидании внешней операции, а процесс — изолировать CPU-bound вычисление от GIL в CPython.
В обработчике нужно сначала обновить локальный кэш, а затем отправить уведомление. Разработчик запускает две корутины и рассчитывает, что корутина обновления завершится раньше корутины уведомления, поскольку она была создана первой.
Вариант с сохранением текущего порядка запуска может работать в тестах, но не даёт контрактной гарантии и ломается при добавлении сетевого ожидания. Вариант с блокировкой защищает критическую секцию, но сам по себе не выражает зависимость «уведомление только после обновления».
Надёжное решение — явно связать операции через asyncio.Event, Future или очередь: корутина обновления сообщает о завершении, а корутина уведомления ожидает этот сигнал. Такой подход немного усложняет структуру, зато не зависит от внутреннего порядка event loop и сохраняет корректность при изменении задержек и нагрузки.
Дополнительный вопрос 1: достаточно ли await для гарантированного переключения на другую корутину?
Нет. Переключение зависит от того, приостанавливает ли фактически ожидаемый объект текущую корутину. Ожидание уже завершённого Future может не создать полноценной паузы, а длительный синхронный код между точками ожидания продолжает выполняться монопольно.
Если требуется гарантированно уступить управление циклу, используют подходящий механизм планирования, например asyncio.sleep(0), но это лишь уступка управления, а не гарантия запуска определённой корутины первой. Для зависимости между задачами нужен явный примитив синхронизации.
Дополнительный вопрос 2: может ли корутина полностью заблокировать остальные задачи, даже если event loop однопоточный?
Да. Однопоточность не означает автоматическое вытеснение. Пока корутина выполняет обычный Python-код и не возвращает управление через приостанавливающий await, event loop не может запустить другие задачи.
Поэтому CPU-bound вычисления и блокирующие вызовы внутри корутины нужно выносить из event loop. Иначе задержка одной операции становится задержкой всех задач, обслуживаемых этим loop.
Дополнительный вопрос 3: как реализовать строгий порядок обработки, если порядок планировщика ненадёжен?
Порядок нужно сделать частью протокола приложения. Например, производитель помещает элементы в asyncio.Queue, а один потребитель обрабатывает их последовательно; либо следующая операция начинает работу только после установки события или завершения Future.
Несколько потребителей позволяют повысить пропускную способность, но тогда последовательность результатов нужно контролировать отдельно: нумеровать элементы, хранить результаты и публиковать их по порядку либо использовать другой механизм сериализации. Такой дизайн явно задаёт требование и не зависит от случайного порядка готовности корутин.