Откуда TaskGroup берёт приоритет дочерней задачи, если его не указали явно?
Если при добавлении задачи в TaskGroup приоритет не задан явно, дочерняя задача наследует приоритет текущей родительской задачи. Это наследование не означает строгую гарантию порядка выполнения: планировщик может изменять фактическое расписание, а приоритет может быть повышен из-за зависимости между ожидающей и ожидаемой задачами.
Structured concurrency была введена, чтобы дочерние задачи были связаны с родительским контекстом, а не существовали как полностью независимые операции. Вместе с областью жизни, отменой и task-local значениями дочерние задачи обычно получают и контекст планирования, включая приоритет.
Для независимых фоновых операций существует Task.detached, который намеренно не наследует такой контекст. Это позволяет явно отделить работу от родительской задачи, но одновременно лишает разработчика автоматического распространения многих гарантий структурированной конкурентности.
Представим высокоприоритетную задачу, которая создаёт группу для параллельной загрузки данных. Если дочерние операции неожиданно получат низкий приоритет, критичный сценарий может дольше ждать результата, несмотря на высокий приоритет родителя.
Обратная ошибка тоже опасна: нельзя считать приоритет механизмом синхронизации или гарантией немедленного запуска. Приоритет влияет на планирование, но не устраняет гонки данных, не фиксирует порядок выполнения и не делает операцию атомарной.
У TaskGroup.addTask параметр приоритета может быть не задан. В этом случае Swift использует приоритет текущей задачи, из контекста которой добавляется дочерняя задача. Поэтому обычная дочерняя задача группы наследует приоритет родителя, в отличие от detached-задачи, для которой приоритет и остальные свойства контекста не наследуются автоматически.
Наследование происходит при создании дочерней задачи. Однако фактический эффективный приоритет может измениться позже. Например, если более приоритетная задача ожидает результат менее приоритетной, планировщик может повысить приоритет ожидаемой работы, чтобы уменьшить задержку зависимости.
Приоритет не является очередью и не гарантирует, что задача с большим значением начнёт выполняться первой. Он лишь предоставляет планировщику информацию о важности работы. Для безопасности общего изменяемого состояния по-прежнему нужны actor, Mutex или другой корректный механизм синхронизации.
Явное задание приоритета оправдано, когда дочерняя операция действительно имеет требования, отличные от родительского контекста. Но искусственное повышение приоритета может привести к конкуренции за ресурсы и вытеснить более важную работу, поэтому его не следует использовать как универсальное средство ускорения.
Сервис синхронизации запускает в одной группе несколько операций: обновление отображаемых данных и построение необязательного аналитического отчёта. Группа создана из высокоприоритетной задачи, поэтому без дополнительных указаний обе дочерние задачи унаследуют этот приоритет.
Вариант с наследованием прост и согласован с контекстом родителя, но аналитическая работа может конкурировать с обновлением интерфейса. Вариант с явным снижением приоритета отчёта лучше разделяет важность операций, но требует осознанного решения и не должен использоваться для исправления проблем производительности без измерений.
Практическое решение — оставить наследование для критичных операций, а второстепенную работу запускать с явно выбранным более низким приоритетом либо вынести в отдельный жизненный цикл. Синхронизацию общего состояния при этом обеспечивают независимо от приоритета, например через actor.
Нет. Приоритет влияет на решение планировщика, но задача может ждать доступности исполнителя, других ресурсов или продолжения родительского контекста. Нельзя выводить из приоритета порядок начала или завершения задач.
Нет. Приоритет не меняет правила доступа к памяти и не сериализует выполнение. Две задачи с самым высоким приоритетом всё равно могут одновременно обращаться к общему изменяемому состоянию; для защиты нужны изоляция actor, блокировка или другой безопасный протокол владения данными.
Нет. Наследуемое начальное значение может измениться из-за динамического повышения приоритета, например когда более приоритетная задача ожидает результат дочерней. Поэтому корректнее говорить о наследовании исходного контекста, а не о неизменной числовой характеристике на всём жизненном цикле задачи.