Краткий ответ

Нет. Порядок создания Task не гарантирует ни порядок начала их выполнения, ни порядок завершения. Если порядок является частью логики, его нужно выразить явной зависимостью: последовательным await, передачей результата или другим механизмом синхронизации.

Исторический контекст

Модель конкурентности Swift отделяет описание асинхронной работы от решения планировщика о том, когда именно дать ей процессор. Такой подход позволяет эффективно использовать пул потоков и не привязывать корректность программы к конкретному расписанию.

Изначально это решает проблему ручного управления потоками: разработчик описывает задачи и зависимости между ними, а не распределяет их по потокам. Обратная сторона — порядок запуска независимых задач нельзя использовать как неявный протокол взаимодействия.

Постановка проблемы

Создание Task лишь регистрирует новую асинхронную работу. Между созданием двух задач планировщик может переключиться на другую задачу, отложить одну из них или выполнить их в другом порядке.

Если программа предполагает, что первая созданная задача уже изменила состояние к моменту запуска второй, возникает гонка: результат зависит от планирования. Даже одинаковый порядок в нескольких запусках не является гарантией Swift.

Подробное решение

Планировщик учитывает доступность исполнителя, приоритет, точки приостановки и другие внутренние условия. Приоритет может влиять на выбор задачи, но не превращает его в строгую очередь и не гарантирует FIFO-поведение.

func start() {
    for number in 1...3 {
        Task {
            print(number)
        }
    }
}

В этом примере допустим любой порядок вывода. Задача может начать выполняться сразу после создания или получить возможность выполнения позднее; полагаться на конкретный порядок нельзя.

Если операции независимы, их можно запускать конкурентно и собирать результаты через структурированные средства Swift. Если вторая операция зависит от первой, зависимость должна быть явной: сначала дождаться результата первой, затем запустить вторую.

Создание задач внутри изолированного контекста может ограничить одновременное выполнение их изолированного кода, но это всё равно не следует трактовать как гарантию порядка их запуска. Сериализация доступа и порядок планирования — разные свойства.

Ситуация из практики

Сервис запускает несколько задач обновления кэша: сначала загружается конфигурация, затем по ней должны запрашиваться данные. Вариант с последовательным созданием двух Task выглядит простым, но не задаёт зависимости: запрос данных может начаться до завершения загрузки конфигурации.

Можно запустить обе операции параллельно, но это неверно, если вторая использует результат первой. Можно добавить задержку, однако это ненадёжно: задержка не синхронизирует задачи и лишь маскирует ошибку.

Правильное решение — сделать зависимость явной: получить конфигурацию через await, затем передать её в операцию загрузки данных. Это немного уменьшает потенциальный параллелизм, зато делает поведение детерминированным и не зависит от планировщика.

Что кандидаты часто упускают

1. Означает ли более высокий приоритет, что задача выполнится первой?

Нет. Приоритет — это подсказка планировщику, а не строгая гарантия очередности. Задача с высоким приоритетом может ждать доступного исполнителя, быть приостановленной на await или зависеть от другой работы.

2. Если задачи созданы внутри одного цикла, выполняются ли они последовательно до первого await?

Нет. Сам факт создания в одном синхронном цикле не превращает задачи в последовательную очередь. Их тела могут начать выполняться между операциями создания, а порядок зависит от контекста и планировщика.

3. Достаточно ли общего actor, чтобы восстановить порядок операций?

Нет. Actor защищает изолированное состояние от одновременного доступа, но порядок независимых обращений не следует выводить из порядка отправки. Если важна последовательность, её нужно моделировать явно: например, хранить состояние переходов внутри actor и выполнять следующий шаг только после завершения предыдущего.