Actors и Sendable — бесплатный тест онлайн

Вопрос 1 из 25

В этом примере важна одна точная деталь механизма «Изоляция акторов». Что действительно произойдёт? Здесь оценивается пересечение границы изоляции актора и атомарность операции.

actor Counter18 {
    var value = 0
    func increment() { value += 1 }
}
func use18(_ c: Counter18) async -> Int {
    await c.increment()
    return await c.value
}

Доступ извне пересекает границу изоляции actor и требует try; после increment возвращается 1. Доступ извне пересекает границу изоляции class и требует await; после increment возвращается 1. Доступ извне пересекает границу изоляции actor и требует await; после increment возвращается 2. Доступ извне пересекает границу изоляции actor и требует await; после increment возвращается 1. Операция с `Counter18` корректна, поскольку порядок завершения задач совпадает с порядком их создания.

Вопрос 2 из 25

Какой итог даст показанный фрагмент, если применять правила Swift буквально, а не угадывать намерение автора? Не упускайте из виду следующее: глобальная actor-изоляция и правильная граница UI.

@MainActor final class Model18 { var text = ""; func update(_ x: String) { text = x } }
func update18(_ model: Model18) async { await model.update("ready") }

Фрагмент не требует отдельного условия: `Sendable` автоматически синхронизирует изменения внутри передаваемого объекта. Вызов из неизвестного контекста переключается на MainActor и требует await. Вызов из неизвестного контекста переключается на глобальный исполнитель и требует await. Вызов из неизвестного контекста переключается на MainActor и требует try. Вызов из неизвестного контекста переключается на MainActor и не требует await.

Вопрос 3 из 25

Не запуская код, восстановите состояние значений после последней строки. Какой вывод верен для «Безопасная передача Sendable»? Важно учесть: доказательство безопасной передачи значения.

struct Message18: Sendable { let id: Int; let text: String }
func transfer18(_ message: sending Message18) async { _ = message }

Для этого примера достаточно учесть, что ссылка на actor открывает синхронный доступ к его состоянию из любой задачи. Последняя строка ведёт себя именно так, потому что `@MainActor` ограничивает только типы UIKit и не действует на обычные свойства. Операция с `Message18` корректна, поскольку `@unchecked Sendable` добавляет блокировку вокруг изменяемых полей. Фрагмент не требует отдельного условия: `Sendable` автоматически синхронизирует изменения внутри передаваемого объекта. Структура из sendable-полей безопасно переносится между областями конкурентности.

Вопрос 4 из 25

Не запуская код, восстановите состояние значений после последней строки. Какой вывод верен для «Гонки данных»? Сосредоточьтесь на следующем: разница между подавлением диагностики и фактической синхронизацией.

actor Safe18 { private var total = 0; func add() { total += 1 }; func read() -> Int { total } }

Сериализация actor предотвращает одновременную несинхронизированную запись total. Фрагмент не требует отдельного условия: `Sendable` автоматически синхронизирует изменения внутри передаваемого объекта. Наблюдаемый результат определяется тем, что порядок завершения задач совпадает с порядком их создания. Сериализация actor не предотвращает одновременную несинхронизированную запись total. Сериализация class предотвращает одновременную несинхронизированную запись total.

Вопрос 5 из 25

Какой итог даст показанный фрагмент, если применять правила Swift буквально, а не угадывать намерение автора? Сосредоточьтесь на следующем: инструментарий и постановка конкурентного теста.

actor Gate18 { private var open = false; func release() { open = true }; func wait() async { while !open { await Task.yield() } } }

Операция с `Gate18` корректна, поскольку `@unchecked Sendable` добавляет блокировку вокруг изменяемых полей. Управляемый gate позволяет синхронизировать этапы конкурентного теста без случайных задержек. Управляемый gate не позволяет синхронизировать этапы конкурентного теста без случайных задержек. Наблюдаемый результат определяется тем, что порядок завершения задач совпадает с порядком их создания. Фрагмент не требует отдельного условия: `Sendable` автоматически синхронизирует изменения внутри передаваемого объекта.

Вопрос 6 из 25

Какой диагноз согласуется и с исходным кодом, и с правилами Swift? Здесь оценивается пересечение границы изоляции актора и атомарность операции.

actor Store18 { var items: [Int] = [] }
func bad18(_ store: Store18) {
    store.items.append(1)
}

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

Вопрос 7 из 25

Что в этом фрагменте нужно объяснить первым, чтобы дальнейшая правка не оказалась случайной? Проверяется глобальная actor-изоляция и правильная граница UI.

@MainActor enum UIState18 { static var status = "idle" }
func sync18() { UIState18.status = "ready" }

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

Вопрос 8 из 25

Что в этом фрагменте нужно объяснить первым, чтобы дальнейшая правка не оказалась случайной? Проверяется доказательство безопасной передачи значения.

final class Box18: Sendable { var value = 0 }

В строгом режиме класс с изменяемым состоянием может автоматически доказать Sendable; простое объявление соответствия небезопасно. В строгом режиме структура с изменяемым состоянием не может автоматически доказать Sendable; простое объявление соответствия небезопасно. В строгом режиме класс с изменяемым состоянием не может автоматически доказать Sendable; простое объявление соответствия небезопасно. Первой нарушенной гарантией здесь является предположение, что `Sendable` автоматически синхронизирует изменения внутри передаваемого объекта. В строгом режиме класс с изменяемым состоянием не может автоматически доказать Codable; простое объявление соответствия небезопасно.

Вопрос 9 из 25

Какую причину стоит указать в отчёте об ошибке, прежде чем предлагать исправление? Важно учесть: разница между подавлением диагностики и фактической синхронизацией.

final class Unsafe18: @unchecked Sendable { var total = 0 }
func add18(_ box: Unsafe18) async {
    await withTaskGroup(of: Void.self) { group in
        for _ in 0..<100 { group.addTask { box.total += 1 } }
    }
}

@unchecked Sendable подавляет проверку, но добавляет синхронизацию; инкременты образуют реальную гонку данных. Наблюдаемый симптом объясняется тем, что порядок завершения задач совпадает с порядком их создания. @unchecked Sendable подавляет проверку, но не добавляет синхронизацию; инкременты образуют реальную гонку данных. @unchecked Codable подавляет проверку, но не добавляет синхронизацию; инкременты образуют реальную гонку данных. Отчёт об ошибке должен указывать, что `Sendable` автоматически синхронизирует изменения внутри передаваемого объекта.

Вопрос 10 из 25

Какой разбор отличает реальную причину от сопутствующего риска? Здесь оценивается инструментарий и постановка конкурентного теста.

final class Unsafe18: @unchecked Sendable {
    var total = 0
}

func raceTest18() async {
    let box = Unsafe18()
    async let first: Void = { box.total += 1 }()
    async let second: Void = { box.total += 1 }()
    _ = await (first, second)
    assert(box.total == 2)
}

Такой тест сам содержит гонку и не становится корректным от того, что ожидает две задачи. Причина сбоя в том, что порядок завершения задач совпадает с порядком их создания. Проблема возникает из-за правила: `@unchecked Sendable` добавляет блокировку вокруг изменяемых полей. Отчёт об ошибке должен указывать, что ссылка на actor открывает синхронный доступ к его состоянию из любой задачи. Такой тест сам содержит гонку и становится корректным от того, что ожидает две задачи.

Вопрос 11 из 25

Какое решение одновременно исправляет код и оставляет понятную границу для дальнейших изменений? Не упускайте из виду следующее: пересечение границы изоляции актора и атомарность операции.

actor Store18 { var items: [Int] = [] }
func bad18(_ store: Store18) {
    store.items.append(1)
}

Добавить метод актора, который выполняет целую операцию внутри изоляции, и вызвать его без await. Добавить метод актора, который выполняет целую операцию внутри изоляции, и вызвать его с await. Достаточно изменить работу с `Store18`, исходя из того, что `Sendable` автоматически синхронизирует изменения внутри передаваемого объекта. Правка сводится к локальному обходу: `@MainActor` ограничивает только типы UIKit и не действует на обычные свойства. Добавить метод актора, который выполняет целую операцию внутри изоляции, и вызвать его с try.

Вопрос 12 из 25

Какой вариант ремонта вы бы приняли после содержательной проверки кода? Важно учесть: глобальная actor-изоляция и правильная граница UI.

@MainActor enum UIState18 { static var status = "idle" }
func sync18() { UIState18.status = "ready" }

Сделать функцию @MainActor или async и выполнить await на изолированном API; использовать DispatchQueue как обход проверки. Сделать функцию @MainActor или async и выполнить await на изолированном API; не использовать DispatchQueue как обход проверки. Сделать функцию @глобальный исполнитель или async и выполнить await на изолированном API; не использовать DispatchQueue как обход проверки. Исправление — оставить контракт прежним и учитывать, что порядок завершения задач совпадает с порядком их создания. Сделать функцию @MainActor или async и выполнить try на изолированном API; не использовать DispatchQueue как обход проверки.

Вопрос 13 из 25

Какое решение одновременно исправляет код и оставляет понятную границу для дальнейших изменений? Не упускайте из виду следующее: доказательство безопасной передачи значения.

final class Box18: Sendable { var value = 0 }

Исправление — оставить контракт прежним и учитывать, что порядок завершения задач совпадает с порядком их создания. Сделать тип неизменяемым, изолировать состояние актором или использовать @unchecked Codable лишь с реально доказанной внешней синхронизацией. Нужно адаптировать только вызов `Box18`, поскольку `@unchecked Sendable` добавляет блокировку вокруг изменяемых полей. Сделать тип неизменяемым, изолировать состояние актором или использовать @unchecked Sendable лишь с реально доказанной внешней синхронизацией. Сигнатуру можно не менять, если считать, что ссылка на actor открывает синхронный доступ к его состоянию из любой задачи.

Вопрос 14 из 25

Как восстановить заявленный контракт с наименьшим числом новых скрытых предположений? Сосредоточьтесь на следующем: разница между подавлением диагностики и фактической синхронизацией.

final class Unsafe18: @unchecked Sendable { var total = 0 }
func add18(_ box: Unsafe18) async {
    await withTaskGroup(of: Void.self) { group in
        for _ in 0..<100 { group.addTask { box.total += 1 } }
    }
}

Достаточно изменить работу с `Unsafe18`, исходя из того, что `Sendable` автоматически синхронизирует изменения внутри передаваемого объекта. Исправление — оставить контракт прежним и учитывать, что порядок завершения задач совпадает с порядком их создания. Нужно адаптировать только вызов `Unsafe18`, поскольку `@unchecked Sendable` добавляет блокировку вокруг изменяемых полей. Сигнатуру можно не менять, если считать, что ссылка на actor открывает синхронный доступ к его состоянию из любой задачи. Защитить состояние актором или блокировкой, охватывающей всю операцию чтение-изменение-запись.

Вопрос 15 из 25

Какое изменение устраняет именно показанную причину и сохраняет ясный контракт «Тестирование и диагностика»? Не упускайте из виду следующее: инструментарий и постановка конкурентного теста.

final class Unsafe18: @unchecked Sendable {
    var total = 0
}

func raceTest18() async {
    let box = Unsafe18()
    async let first: Void = { box.total += 1 }()
    async let second: Void = { box.total += 1 }()
    _ = await (first, second)
    assert(box.total == 2)
}

Включить строгую проверку конкурентности и Thread Sanitizer для поддерживаемого сценария, а тест строить вокруг безопасного наблюдаемого API. Правка сводится к локальному обходу: ссылка на actor открывает синхронный доступ к его состоянию из любой задачи. Нужно адаптировать только вызов `Unsafe18`, поскольку порядок завершения задач совпадает с порядком их создания. Исправление — оставить контракт прежним и учитывать, что `Sendable` автоматически синхронизирует изменения внутри передаваемого объекта. Сигнатуру можно не менять, если считать, что `@unchecked Sendable` добавляет блокировку вокруг изменяемых полей.

Вопрос 16 из 25

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

Ссылка на class может передаваться между задачами безопасно, но его изменяемое состояние остаётся доступным только через изолированные операции. Ссылка на actor не может передаваться между задачами безопасно, но его изменяемое состояние остаётся доступным только через изолированные операции. Контрпример появляется, когда `Sendable` автоматически синхронизирует изменения внутри передаваемого объекта. Граница применимости проходит там, где `@MainActor` ограничивает только типы UIKit и не действует на обычные свойства. Ссылка на actor может передаваться между задачами безопасно, но его изменяемое состояние остаётся доступным только через изолированные операции.

Вопрос 17 из 25

Какое ограничение `MainActor` обязательно проверить отдельным граничным тестом? Не упускайте из виду следующее: глобальную actor-изоляцию и границу обновления интерфейса.

Вызов `@MainActor`-функции из фоновой задачи остаётся синхронным, если функция ничего не возвращает. MainActor задаёт сериализованный исполнитель, но не обещает, что каждая строка всегда выполняется на одном физическом потоке во всех абстракциях. Любой объект, доступный из `@MainActor`-типа, автоматически становится `Sendable`. `MainActor` гарантирует выполнение на одном и том же физическом потоке до и после каждой точки `await`. `MainActor` изолирует только хранимые свойства, но не ограничивает вызовы методов экземпляра.

Вопрос 18 из 25

Какое уточнение защищает решение от слишком широкого толкования? Не упускайте из виду следующее: доказательство безопасной передачи значения.

Sendable описывает безопасность передачи значения, а не наличие конкретного метода копирования или обязательную неизменяемость синтаксически. Контрпример появляется, когда `@MainActor` ограничивает только типы UIKit и не действует на обычные свойства. Sendable описывает безопасность передачи значения, а наличие конкретного метода копирования или обязательную неизменяемость синтаксически. Codable описывает безопасность передачи значения, а не наличие конкретного метода копирования или обязательную неизменяемость синтаксически. Граница применимости проходит там, где ссылка на actor открывает синхронный доступ к его состоянию из любой задачи.

Вопрос 19 из 25

Какой отрицательный сценарий лучше всего проверяет предел применимости этого механизма? Проверяется разница между подавлением диагностики и фактической синхронизацией.

Даже если тест несколько раз не получает 100, это не доказывает отсутствие гонки: ошибочный межпоточный порядок может не проявиться. Ограничение определяется предположением, что ссылка на actor открывает синхронный доступ к его состоянию из любой задачи. Даже если тест несколько раз получает 100, это не доказывает отсутствие гонки: ошибочный межпоточный порядок может не проявиться. Даже если тест несколько раз получает 101, это не доказывает отсутствие гонки: ошибочный межпоточный порядок может не проявиться. Контрпример появляется, когда `@unchecked Sendable` добавляет блокировку вокруг изменяемых полей.

Вопрос 20 из 25

На какой границе входов, владения или времени жизни результат может стать другим? Здесь оценивается инструментарий и постановка конкурентного теста.

Номер потока в журнале недостаточен для class-диагностики; важнее область изоляции и последовательность точек await. Граница применимости проходит там, где `@unchecked Sendable` добавляет блокировку вокруг изменяемых полей. Номер потока в журнале недостаточен для actor-диагностики; важнее область изоляции и последовательность точек await. Номер потока в журнале недостаточен для actor-диагностики; важнее область изоляции и последовательность точек try. Пограничный случай связан с тем, что порядок завершения задач совпадает с порядком их создания.

Вопрос 21 из 25

Какой принцип важнее локальной красоты синтаксиса в рабочем приложении? Важно учесть: пересечение границы изоляции актора и атомарность операции.

Метод actor лучше проектировать как атомарное бизнес-действие; последовательность нескольких try между чтением и записью допускает вмешательство других задач. В API и тестах следует исходить из правила: `@MainActor` ограничивает только типы UIKit и не действует на обычные свойства. Для устойчивого решения достаточно принять, что `Sendable` автоматически синхронизирует изменения внутри передаваемого объекта. Метод actor лучше проектировать как атомарное бизнес-действие; последовательность нескольких await между чтением и записью допускает вмешательство других задач. Метод class лучше проектировать как атомарное бизнес-действие; последовательность нескольких await между чтением и записью допускает вмешательство других задач.

Вопрос 22 из 25

Какой принцип важнее локальной красоты синтаксиса в рабочем приложении? Не упускайте из виду следующее: глобальная actor-изоляция и правильная граница UI.

Главным проектным принципом здесь является утверждение, что `@unchecked Sendable` добавляет блокировку вокруг изменяемых полей. При расширении системы нужно опираться на то, что порядок завершения задач совпадает с порядком их создания. UI-модель обычно целиком изолируют на MainActor, чтобы разбрасывать точечные переключения и не оставлять половину состояния без защиты. UI-модель обычно целиком изолируют на глобальный исполнитель, чтобы не разбрасывать точечные переключения и не оставлять половину состояния без защиты. UI-модель обычно целиком изолируют на MainActor, чтобы не разбрасывать точечные переключения и не оставлять половину состояния без защиты.

Вопрос 23 из 25

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

@unchecked Sendable переносит ответственность с компилятора на автора и не должен сопровождаться ясным инвариантом блокировки. Главным проектным принципом здесь является утверждение, что порядок завершения задач совпадает с порядком их создания. @unchecked Codable переносит ответственность с компилятора на автора и должен сопровождаться ясным инвариантом блокировки. @unchecked Sendable переносит ответственность с компилятора на автора и должен сопровождаться ясным инвариантом блокировки. @unchecked Sendable не переносит ответственность с компилятора на автора и должен сопровождаться ясным инвариантом блокировки.

Вопрос 24 из 25

Какое замечание на проверке кода поможет предотвратить повторение такого дефекта? Не упускайте из виду следующее: разница между подавлением диагностики и фактической синхронизацией.

защита от гонок данных и логическая гонка различны: actor убирает одновременный доступ, но порядок двух корректных сообщений всё ещё не может менять бизнес-результат. защита от гонок данных и логическая гонка различны: class убирает одновременный доступ, но порядок двух корректных сообщений всё ещё может менять бизнес-результат. В API и тестах следует исходить из правила: порядок завершения задач совпадает с порядком их создания. Главным проектным принципом здесь является утверждение, что `Sendable` автоматически синхронизирует изменения внутри передаваемого объекта. защита от гонок данных и логическая гонка различны: actor убирает одновременный доступ, но порядок двух корректных сообщений всё ещё может менять бизнес-результат.

Вопрос 25 из 25

Что стоит закрепить в типах или API, а не оставлять устной договорённостью? Здесь оценивается инструментарий и постановка конкурентного теста.

Для устойчивого решения достаточно принять, что `@unchecked Sendable` добавляет блокировку вокруг изменяемых полей. Архитектуру стоит строить из предположения, что ссылка на actor открывает синхронный доступ к его состоянию из любой задачи. При расширении системы нужно опираться на то, что `@MainActor` ограничивает только типы UIKit и не действует на обычные свойства. В API и тестах следует исходить из правила: порядок завершения задач совпадает с порядком их создания. Сначала устранить предупреждения компилятора, затем искать логические гонки детерминированными сценариями порядка сообщений.