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

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

Компилятор рассматривает тела конкурентных задач как потенциально выполняющиеся одновременно. Поэтому он не разрешает захватывать изменяемую переменную способом, безопасность которого нельзя доказать статически.

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

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

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

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

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

Например, две задачи могут одновременно прочитать значение 0, обе вычислить 1, а затем записать 1. Ожидаемый результат 2 будет потерян. Даже если конкретный запуск обычно даёт правильный результат, это не является гарантией корректности.

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

Конкурентное замыкание обычно анализируется как Sendable-контекст: его захватываемые данные должны быть безопасны для передачи между задачами. Простая изменяемая локальная переменная не предоставляет такой гарантии, поскольку её состояние может совместно изменяться без координации.

Типичное сообщение компилятора указывает на захват изменяемой переменной конкурентно выполняющимся кодом. Это не означает, что сам тип Int небезопасен: проблема состоит в общей изменяемой ячейке памяти, а не в значении Int как таковом.

Минимальный пример проблемы и исправления:

var total = 0
await withTaskGroup(of: Void.self) { group in
    group.addTask {
        total += 1 // Ошибка: общая изменяемая переменная
    }
}

actor Counter {
    private var value = 0
    func increment() { value += 1 }
}

let counter = Counter()
await withTaskGroup(of: Void.self) { group in
    for _ in 0..<2 {
        group.addTask { await counter.increment() }
    }
}

Actor изолирует своё изменяемое состояние: одновременно выполнять изолированные методы, обращающиеся к этому состоянию, нельзя. В данном примере increment не содержит точки приостановки, поэтому операция чтения, увеличения и записи выполняется как единый изолированный вызов.

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

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

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

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

Третий вариант помещает счётчик в actor. Он проще для общего состояния и централизует инварианты, но каждый доступ к нему становится изолированным вызовом, а большое число мелких обращений может добавить накладные расходы.

Для счётчика, который обновляется часто, предпочтителен вариант с локальными частичными результатами и последующим объединением. Actor разумнее выбрать, если состояние имеет несколько связанных операций или используется разными компонентами приложения.

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

1. Является ли проблема следствием того, что задачи обязательно работают на разных потоках?

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

2. Устраняет ли await перед изменением переменной гонку данных?

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

3. Достаточно ли сделать переменную константой, чтобы передавать её нескольким задачам?

Не всегда. Неизменяемое значение обычно безопаснее, но важно учитывать его тип: ссылка на константный экземпляр всё ещё может вести к изменяемому ссылочному объекту. Поэтому безопасность определяется не только ключевым словом let, но и тем, является ли передаваемое значение действительно безопасным для конкурентного доступа, в частности соответствует ли оно требованиям Sendable.