Гарантирует ли Swift выполнение одной async-задачи на одном и том же потоке до её завершения?
Нет. async-задача не закрепляется за конкретным потоком: после приостановки на await она может продолжить работу на другом потоке, выбранном соответствующим исполнителем. Код не должен зависеть от идентификатора потока; требуемую последовательность доступа обеспечивает изоляция actor или глобального actor, а не поток.
Традиционная модель часто связывала выполняемую операцию с выделенным потоком. Это упрощало рассуждение о текущем потоке, но при большом числе операций приводило к расходу потоков и блокировкам во время ожидания ввода-вывода.
Модель async/await отделяет логическую операцию от физического потока. Пока задача ожидает результат, поток может выполнять другую работу, а после готовности результата среда выполнения возобновляет задачу на доступном потоке.
Если разработчик предполагает, что задача всегда возвращается на исходный поток, он может неявно привязать к этому предположению доступ к UI, thread-local данным или синхронному состоянию. Такое решение либо приводит к ошибке доступа, либо случайно скрывает гонку данных.
Важно отличать поток от изоляции. Поток — ресурс выполнения, а actor — механизм, задающий допустимый порядок доступа к изолированному состоянию.
До первого await задача выполняет синхронный фрагмент на потоке, который назначил её исполнитель. При достижении точки приостановки задача сохраняет необходимое состояние и освобождает поток; после возобновления другой поток может выполнить продолжение.
Swift не обещает сохранение исходного потока для обычной async-функции. Даже если два участка выполняются на одном потоке в конкретном запуске, это наблюдаемое обстоятельство, а не контракт API.
Если функция изолирована MainActor, её изолированные участки должны выполняться в контексте MainActor, что обычно означает главный исполнитель и главный поток, но полагаться на поток как на универсальный механизм безопасности всё равно не следует. Для обычного actor гарантируется сериализованный доступ к его изолированному состоянию, а не выполнение на определённом потоке.
Нельзя исправлять проблему простым сохранением идентификатора потока или использованием thread-local хранилища. После await это состояние может оказаться недоступным или не соответствовать текущему месту продолжения. Следует передавать данные явно и применять actor, Sendable, блокировку либо другой подходящий механизм синхронизации.
Сервис загружает данные и затем обновляет модель экрана. Разработчик предполагает, что после ожидания загрузки код продолжит работу на том же фоне́вом потоке, где началась операция, и хранит промежуточное состояние в привязанном к потоку хранилище.
Вариант с выделенным потоком сохраняет такое предположение, но плохо масштабируется: поток простаивает во время ожидания и усложняет отмену и управление ресурсами. Вариант с обычной async-задачей эффективнее, однако требует отказаться от зависимости от потока.
Корректное решение — хранить состояние в обычных значениях или в actor, а обновление UI выполнять через MainActor. Тогда смена потока после await не меняет корректность программы, а доступ к состоянию определяется изоляцией и проверяется компилятором.
Если задача может сменить поток, означает ли это, что её код может выполняться параллельно сам с собой?
Нет. Перемещение между потоками не означает одновременное выполнение одного продолжения. В каждый момент конкретный выполняемый участок задачи исполняется последовательно, но разные задачи могут одновременно обращаться к общим данным. Без изоляции или синхронизации это создаёт гонку данных.
Гарантирует ли await переход на другой поток?
Нет. await обозначает возможную приостановку, а не обязательную смену потока. Если результат уже доступен или исполнитель может продолжить работу без фактического ожидания, задача может не приостанавливаться и продолжить выполнение на том же потоке.
Достаточно ли проверить текущий поток перед обращением к состоянию actor?
Нет. Проверка потока не доказывает наличие нужной actor-изоляции. Actor может быть связан с собственным исполнителем, а не с конкретным потоком; корректный доступ должен проходить через правила изоляции Swift, например вызов actor-изолированного метода с await или выполнение в контексте соответствующего глобального actor.