Асинхронное программирование

Асинхронное программирование – это стиль построения программ, при котором операции, потенциально длительно ожидающие внешних событий (ввода-вывода, таймеров, сетевых ответов), не блокируют исполнение остальных частей программы. Вместо ожидания поток «делегирует» продолжение вычисления диспетчеру событий, а результат возвращается через колбэки/фьючерсы/корутины.

Для подготовки к ЕГЭ по информатике тема полезна тем, что:

• учит формализовать графы зависимостей задач, строить конвейеры и анализировать инварианты;
• развивает навыки доказательства корректности через модель памяти и отношение happens-before;
• тренирует оценку асимптотик и производительности, сопоставление параллелизма и конкурентности.

Понятийный аппарат и формальные определения

1. Синхронность, конкурентность, параллелизм
   

   • Синхронное выполнение: вызов f() занимает поток до возврата результата.

   • Асинхронное выполнение: вызов f_async() инициирует операцию и немедленно возвращает управляющий объект (колбэк/фьючерс/задача). Продолжение выполняется позже.

   • Конкурентность – логическое переплетение независимых операций; параллелизм – фактическая одновременность на разных ядрах. Асинхронность даёт конкурентность без обязательного параллелизма.

2. Событийная система и цикл событий
   

   Рассмотрим абстракцию:

   E = <Q, H, S, δ, π>

   Q – очередь событий,

   H – набор обработчиков,

   S – внутреннее состояние,

   δ – функция переходов состояния,

   π – планировщик (event loop).

   Цикл событий (event loop) извлекает событие из Q, находит обработчик из H, применяет переход δ, возможно планирует новые события.

3. Единицы работы
   

   • Callback – функция-продолжение.

   • Future/Promise – контейнер результата, меняющий состояние {pending, fulfilled, rejected}.

   • Coroutine (async/await) – кооперативная единица, при await отдаёт управление планировщику, сохраняя стек (машина состояний).

Модели исполнения: от колбэков к корутинам

1. Модель колбэков
   

   Граф продолжений – ориентированный ациклический граф (DAG), где вершины – обработчики, рёбра – зависимость «после завершения A запустить B».
   Правило К1: каждое ребро должно соответствовать единственному источнику завершения (иначе многократные вызовы приведут к дублированию побочных эффектов).

2. Фьючерсы/промисы
   

   Определим интерфейс:

   Future<T> = <state, value, error, continuations>

   add_continuation(f): если state = pending, добавить f; иначе выполнить немедленно.

   Правило F1 (монотонность): состояние переходит pending → fulfilled или pending → rejected ровно один раз.
   Правило F2 (идемпотентность): продолжение должно корректно обрабатываться при немедленном и отложенном запуске (отсутствие гонок и повторной подписки).

3. Корутины (async/await)
   

   Корутина – это конечный автомат:

   M = <Q, q0, F, δ>

   q0 – начальное состояние (до первого await),

   δ(q, событие_результата) → q', пока не достигнем финала F.

   Правило C1 (точки приостановки): выносите побочные эффекты после await, либо обеспечьте идемпотентность – при повторном запуске из сохранённого состояния не нарушайте инварианты.

Модель памяти и порядок событий

1. Отношение happens-before
   

   Определим →_hb как наименьшее отношение, содержащее:

   1. Программный порядок внутри задачи,

   2. Синхронизацию (постановка колбэка/результата и его выполнение),

   3. Транзитивность.

   Если A →_hb B, то эффекты A видимы в B.
   Правило М1: обмен данными между асинхронными частями возможен только через точки синхронизации (завершение фьючерса, отправка в канал, мьютекс, атомики).

2. Атомарность и неизменяемость
   

   • Неизменяемые структуры безопаснее для передачи между задачами.

   • Атомарные операции гарантируют корректный подсчёт/флаги без мьютексов в простых случаях.
     Правило М2: общие изменяемые объекты избегайте; если неизбежно – инкапсулируйте доступ в одну «петлю» (actor-подход).

Неблокирующий ввод-вывод и планирование

1. Готовность vs завершение
   

   • Модель готовности (select/poll/epoll/kqueue): планировщик уведомляет, что дескриптор готов к чтению/записи.

   • Модель завершения (completion ports): планировщик доставляет событие о факте завершения операции.

2. Оценка трудоёмкости (идеализировано)
   

   Пусть N – число активных дескрипторов, E – событий за интервал. Тогда:

   Время обработки ≈ O(E) + O(cost_dispatch) + O(cost_callbacks)

   Пробуждение цикла ≈ O(log N) или O(1) (зависит от ядра и структуры очереди)

   Правило I/O1: объединяйте мелкие операции в пачки (batch) и используйте конвейеризацию.

Управление временем: таймеры, таймауты, отмена

1. Таймауты
   

   Для операции с бюджетом Δt вводим ограничение:

   если t_факт > Δt, операция отменяется и публикуется ошибка Timeout.

   Правило T1: у каждой внешней операции должен быть таймаут по умолчанию.

2. Отмена
   

   Передаётся токен CancelToken.
   Правило T2: отмена кооперативна: обработчик регулярно проверяет токен в точках ожидания; отмена означает «больше неинтересен результат», а не «жёстко прервать» исполнение в произвольный момент.

Сопряжение синхронного и асинхронного кода

Правило S1: не вызывайте блокирующие операции внутри цикла событий. Оборачивайте в пул рабочих (thread-pool) с обратной доставкой результата.
Правило S2: при переходе «синхронный → асинхронный» верните задачу/фьючерс; при переходе «асинхронный → синхронный» используйте ожидание вне главного цикла, чтобы избежать взаимоблокировки.

Шаблоны проектирования

1. Fan-out/Fan-in – параллельный запуск независимых задач и сбор результатов (порядок – по готовности).
2. Pipeline – стадии produce → transform → consume, каждая – независимая асинхронная функция; между стадиями – буфер (канал).
3. Retry с джиттером – экспоненциальные паузы с шумом для снижения синхронности «стада».
4. Circuit Breaker – временная «отсечка» неудачных вызовов поставщика.
5. Backpressure – управление скоростью источника по заполнению буфера.

Правило P1: в конвейере длина очереди ограничена:

0 ≤ size(queue) ≤ Qmax

Если size(queue) = Qmax, производитель должен ждать или отбрасывать (в соответствии с политикой).

Анти-паттерны (типичные ошибки)

• Unawaited tasks – запущенные и забытые задачи → утечки, гонки завершения.
• Shared Mutable State – разделяемые изменяемые объекты без синхронизации.
• Blocking in Event Loop – длинные CPU-участки в главном цикле → «замерзание» UI/сервера.
• Бесконтрольные ретраи – усиление нагрузки на деградирующий сервис.
• Забытые таймауты/отмена – «вечные» операции.

Производительность: простые формулы и оценки

Пусть:

• λ_req – интенсивность входящих запросов (заявок/сек),
• t_cpu – среднее CPU-время на запрос,
• t_io – среднее «чистое» I/O-ожидание на запрос,
• p_overlap – доля перекрытия ожидания с работой других задач.

Тогда среднее время ответа (грубо):

Tresp ≈ t_cpu + (1 - p_overlap) * t_io + Toverhead

Где Toverhead – накладные расходы диспетчера и синхронизаций.
Пропускная способность:

Throughput ≈ 1 / Tresp   (для одного «рабочего слота»).

С увеличением конкурентности C (числа одновременно выполняемых задач) при I/O-доминировании достигается

Throughput ≈ C / Tresp

до насыщения диска/сети/ЦП.

Мини-шпаргалка 

R1  Подстановки/кавычки: сохраняйте границы аргументов (в асинхронных CLI-задачах).

F1  Future меняет состояние ровно один раз.

C1  Побочные эффекты – после await или делайте их идемпотентными.

M1  Данные делите через синхронизацию; immutable – предпочтительны.

I/O1 Батчируйте операции; избегайте мелких чтений/записей.

T1  Каждая внешняя операция имеет таймаут.

T2  Отмена кооперативна и наблюдаема в точках ожидания.

S1  Не блокируйте event loop; CPU-участки → в пул.

P1  Ограничивайте буферы; реализуйте backpressure.

QA  Покрывайте крайние случаи: таймаут, отмена, частичный успех.

Связь с ЕГЭ по информатике

• Графы и автоматы: корутина как конечный автомат; планирование как обход событийного графа.
• Алгоритмы и оценки: анализ O(n) конвейеров, очередей, буферов.
• Логика и инварианты: happens-before, атомарность, корректность обмена сообщениями.
• Моделирование систем: задание состояний/переходов, рассуждение о тайм-ауте/отмене.
• Практикум: формирование строгих контрактов функций (ввод/вывод/ошибки), работа со случаями отказа.

Пять упражнений (академический формат)

Упражнение 1. Автомат корутины и идемпотентность

Задача. Смоделируйте корутину FetchThenStore, выполняющую: (1) сетевой запрос, (2) запись результата в хранилище. Сетевая часть может завершиться с ошибкой/таймаутом; запись – повторяемая операция.
a) Постройте конечный автомат M = <Q, q0, F, δ> с состояниями: Start, AwaitNet, NetOk, NetErr, Store, Done.
b) Сформулируйте инвариант: «если запись начата, то в хранилище окажется ровно одна версия результата».
c) Предложите стратегию: делать запись после await и делать её идемпотентной (например, PUT по ключу с той же версией). Докажите, что повторный запуск из Store не нарушает инвариант.

Упражнение 2. Backpressure и предел производительности

Дано. Источник генерирует элементы со скоростью λ_prod = 5000 элементов/с. Обработчик справляется со скоростью λ_cons = 3000 элементов/с. Буфер ограничен Qmax = 1000.
a) Выведите условие устойчивости конвейера: λ_prod ≤ λ_cons.
b) Через сколько секунд переполнится буфер, если не вводить ограничение источника?
Δλ = λ_prod - λ_cons = 2000 эл/с
t_overflow = Qmax / Δλ = 1000 / 2000 = 0.5 с
c) Предложите политику: «блокировать/замедлять» источник при size(queue) ≥ Qmax·0.8 и сбрасывать «наименее важные» элементы при size(queue)=Qmax.

Упражнение 3. Анализ happens-before

Сценарий. Задача A заполняет структуру S и завершает фьючерс F значением ссылки на S. Задача B, дожидаясь F, читает S.
a) Опишите →_hb: запись в S в A должна предшествовать чтению S в B через факт завершения F.
b) Приведите контрпример гонки: чтение B без ожидания F.
c) Сформулируйте правило: «все публикации данных – до fulfill, все чтения – после await».

Упражнение 4. Смешивание блокирующих вызовов

Ситуация. Внутри обработчика события выполняется синхронное чтение файла размером 100 МБ.
a) Объясните, почему это «замораживает» цикл событий.
b) Предложите переписывание: вынести операцию в пул рабочих и вернуть фьючерс.
c) Оцените Tresp до/после:
До:  Tresp ≈ t_io(100МБ)  (блокирует всех)
После: Tresp ≈ Toverhead + min(t_io, перекрыто остальными задачами)

Упражнение 5. Таймауты, отмена и ретраи

Условие. Вызов внешнего API имеет среднее время 250 мс, дисперсию высокую; SLA – не более 700 мс на запрос.
a) Выберите таймаут запроса Δt (например, 500 мс) и количество ретраев k (например, 1) с джиттером 50–150 мс.
b) Докажите, что P(превышение SLA) снижается при разумном k, но излишний k увеличивает нагрузку; сформулируйте критерий остановки: «отмена цепочки при срабатывании внешнего таймера 700 мс».
c) Запишите псевдоконтракт:
{ P: Δt ≤ 500мс, k ≤ 1, общий таймер 700мс }
call_async(req) -> Future<res|Timeout|Cancel>
{ Q: либо res до 700мс, либо контролируемая ошибка Timeout/Cancel }

Заключение

Асинхронное программирование – это строгая вычислительная модель с чёткими правилами синхронизации, публикации данных и управления временем. В ней центральны: граф продолжений, конечные автоматы корутин, happens-before, таймаут/отмена, backpressure и конвейеры. Осваивая эти принципы и решая приведённые упражнения, вы формируете навыки, критичные для задач ЕГЭ: формализацию состояний, доказательство корректности, оценку асимптотик и аккуратную работу с пограничными случаями.