Heart of Swift Concurrency

Transcript

1. Heart of Swi, Concurrency @koher
2. Heart of Swi,
4. Value Seman*cs Protocol-oriented Programming
5. Heart of Swi,
6. Heart of Swi, Concurrency
7. Swi$ Concurrencyは難しい？
8. Concurrencyの仕様は膨大で複雑
9. しかし、そのHeartはシンプル
10. Heartを押さえれば見通しがよくなる
11. Heart of Swi, Concurrency
12. Swi$ ConcurrencyのHeartとは？
13. Data Race Safety
14. コンパイラがデータ競合を防止すること
15. Isola&on Domain Sendable
16. データ競合とは？
18. データ競合が起こると • 未定義動作 • データ不整合 • クラッシュ • …
19. データ競合によるバグには対処しづらい • 問題を再現することが困難 • 原因を突き止めるのが困難 • コードを修正して解決されたことの確認が困難
20. データ競合を機械的に防止できるとうれしい
21. Strict Concurrency Checking
22. 原因不明のクラッシュのほとんどが データ競合によって引き起こされていた例も
23. Swi$コンパイラは どのようにデータ競合を防ぐのか
24. Swi$コンパイラは 型を使ってデータ競合を防ぐ
25. Isola&on Domain Sendable
26. Isola&on Domain
27. Isola&on Domainとは？
28. 可変状態へのアクセスを 隔離して保護する単位
29. Isola&on Domainのカテゴリー all func&on and variable declara&ons have a well-defined sta&c isola&on domain. These domains will always fall into one of three categories: 1. Non-isolated 2. Isolated to an actor value 3. Isolated to a global actor 2 "Migra)ng to Swi/ 6" h2ps://www.swi/.org/migra)on/documenta)on/swi/-6-concurrency-migra)on-guide/ dataracesafety#Isola)on-Domains
30. Isola&on Domainのカテゴリー すべての関数宣言と変数宣言には、静的に定まるIsola&on Domain があります。Isola&on Domainは必ず、次の3つのカテゴリーのい ずれかに分類されます。 1. 隔離されていない（Non-isolated） 2. Actorの値に隔離されている 3. Global Actorに隔離されている
31. Isola&on Domainのカテゴリー すべての関数宣言と変数宣言には、静的に定まるIsola&on Domain があります。Isola&on Domainは必ず、次の3つのカテゴリーのい ずれかに分類されます。 1. 隔離されていない（Non-isolated） 2. Actorの値に隔離されている 3. Global Actorに隔離されている
32. ActorとIsola*on Domain actor Counter { // 可変状態countはCounterインスタンスに隔離されて保護される var count: Int = 0 } func countUp() { count += 1 }
34. Actor以前も同じようなことを DispatchQueueでやっていた
35. Actorはそれを自動的にやってくれる
36. 外部からActorにアクセスするにはawaitが必要 let counter: Counter = .init() await counter.countUp() // awaitが必要 print(await counter.count) // awaitが必要
37. ActorのIsola*on Domainはインスタンスごとに存在 let a: Counter = .init() // aのIsolation Domain let b: Counter = .init() // bのIsolation Domain
38. Isola&on Domainのカテゴリー すべての関数宣言と変数宣言には、静的に定まるIsola&on Domain があります。Isola&on Domainは必ず、次の3つのカテゴリーのい ずれかに分類されます。 1. 隔離されていない（Non-isolated） 2. Actorの値に隔離されている 3. Global Actorに隔離されている
39. ActorのIsola*on Domainはインスタンスごとに存在 actor Counter { var count: Int = 0 } func countUp() { ... }
40. ActorのIsola*on Domainはインスタンスごとに存在 actor Counter { var count: Int = 0 func countUp() { ... } func foo() async { let counter: Counter = .init() await counter.countUp() // awaitが必要 print(await counter.count) // awaitが必要 } }
41. 自身のプロパティやメソッドには同期的にアクセス可 actor Counter { var count: Int = 0 func countUp() { ... } func countUpTwice() { countUp() // 同期 countUp() // 同期 } }
42. Isola&on Domainのカテゴリー すべての関数宣言と変数宣言には、静的に定まるIsola&on Domain があります。Isola&on Domainは必ず、次の3つのカテゴリーのい ずれかに分類されます。 1. 隔離されていない（Non-isolated） 2. Actorの値に隔離されている 3. Global Actorに隔離されている
43. Global ActorとIsola-on Domain @MainActor final class FooViewModel { var value: Int = 42 }
44. Global ActorとIsola-on Domain @MainActor final class FooViewModel { var value: Int = 42 } // 暗黙的に@MainActor final class FooViewController: UIViewController { let viewModel: FooViewModel = .init() func buttonPressed() { print(viewModel.value) // 同期 } }
45. Global Actorはインスタンスを超えて Isola&on Domainを形成する
46. Global Actorは種類ごとに 単一のIsola-on Domainを作る
47. Global Actorは種類ごとに 単一のSerial Executorを持つ
49. Isola&on Domainのカテゴリー すべての関数宣言と変数宣言には、静的に定まるIsola&on Domain があります。Isola&on Domainは必ず、次の3つのカテゴリーのい ずれかに分類されます。 1. 隔離されていない（Non-isolated） 2. Actorの値に隔離されている 3. Global Actorに隔離されている
50. TaskとIsola&on Domain Task { // Task独自のnon-isolatedなIsolation Domain }
51. non-isolatedなのにIsola,on Domain？
52. TaskとIsola&on Domain Task { // Task独自のnon-isolatedなIsolation Domain var value: Int = 42 }
53. 一つのTaskの中からアクセスする限り 可変状態はデータ競合を起こさない
54. TaskとIsola&on Domain Task { // Task独自のnon-isolatedなIsolation Domain }
55. TaskとIsola&on Domain @MainActor func foo() { // MainActor-isolated Task { // MainActor-isolated } }
56. TaskとIsola&on Domain @MainActor func foo() { // MainActor-isolated Task.detached { // Task独自のnon-isolatedなIsolation Domain } }
57. Isola&on Domainのカテゴリー すべての関数宣言と変数宣言には、静的に定まるIsola&on Domain があります。Isola&on Domainは必ず、次の3つのカテゴリーのい ずれかに分類されます。 1. 隔離されていない（Non-isolated） 2. Actorの値に隔離されている 3. Global Actorに隔離されている
58. 可変状態を単一のIsola&on Domainで 扱っている分にはデータ競合は起こらない
59. Isola&on Domain間で 値をやりとりできないと困る
60. Isola&on Domain間で共有しても 安全な値だけをやりとりできるようにする
61. 安全な値とそうでないものを区別したい
62. Sendable
63. 共有しても安全な値の型を Sendableプロトコル準拠で区別する
64. ミュータブルクラス final class Foo: Sendable { // var value: Int // 可変 } init(value: Int) { self.value = value } 同時にvalueにアクセスされるとデータ競合の原因となり得る
65. イミュータブルクラス final class Foo: Sendable { // let value: Int // 不変 } init(value: Int) { self.value = value } 可変状態を持たないのでデータ競合の原因とならない
66. （純粋な）値型 struct Foo: Sendable { // var value: Int // 可変でもOK } init(value: Int) { self.value = value } 渡すときにコピーされるのでそもそも共有されない ✅
67. Actor actor Foo { // ✅ 自動的にSendable準拠 var value: Int // 可変でもOK } init(value: Int) { self.value = value } valueはSerial Executorで保護されている
68. ロック等で可変状態が保護されたミュータブルクラス final class Foo: Sendable { // private let mutex: Mutex<Int> var value: Int { get { mutex.withLock { $0 } } set { mutex.withLock { $0 = newValue } } } } init(value: Int) { self.mutex = .init(value) }
69. Isola&on Domain間で共有されても安全な 値の型をSendableで区別できた
70. non-Sendableな値が Isola(on Domain間で共有されなければ Data Race Safetyを保証できる
72. Isola&on Boundaryの例 異なるIsola&on Domain間で • 関数やメソッドの引数に値を渡す • 戻り値として値を受け取る • クロージャに値をキャプチャする • …
73. non-Sendableな値が Isola(on Boundaryを越えようとしていたら コンパイラがエラーにする
74. コンパイラがData Race Safetyを保証
75. Sendable準拠という型の情報を使って 巧妙にData Race Safetyを実現
76. しかし、このチェックは保守的すぎる
77. Isola&on Domain間で共有されない ≠ Isola&on Boundaryを越えない
79. non-SendableがIsola(on Boundaryを越えていい例 final class Foo { // non-Sendable var value: Int = 42 }
80. non-SendableがIsola(on Boundaryを越えていい例 actor A { var foo: Foo } func accept(_ foo: Foo) { self.foo = foo }
81. non-SendableがIsola(on Boundaryを越えていい例 let a: A = .init() let foo: Foo = .init() await a.accept(foo) // ✅ 作って渡すだけ
82. non-SendableがIsola(on Boundaryを越えてはダメな例 let a: A = .init() let foo: Foo = .init() await a.accept(foo) // foo.value += 1 // ⚠ 越境してはいけない 後から使うとデータ競合を起こし得る ⛔
83. 3 Region-based Isola/on 3 SE-0414: h+ps://github.com/swi9lang/swi9-evolu?on/blob/main/proposals/0414-region-based-isola?on.md
86. 間接的に「作って渡すだけ」の場合 ⛔ await bar(Foo()) // 作って渡すだけ func bar(_ foo: Foo) async { // fooが呼び出し元でもう使用されないか判断できない } await a.accept(foo)
87. 間接的に「作って渡すだけ」の場合 ✅ await bar(Foo()) // 作って渡すだけ func bar(_ foo: sending Foo) async { // fooが呼び出し元でもう使用されないとわかる } await a.accept(foo)
90. これまでのまとめ • Isola'on Domainが可変状態を隔離して保護 • 原則的にはSendableだけがIsola'on Boundaryを越えられる • 安全な場合にはnon-Sendableな値もBoundaryを越えられる • コンパイラが越境をチェックしてData Race Safetyを実現
91. Concurrencyと上手く付き合う方法
92. ! Concurrencyに適したアプリの設計
93. MainActorでやって困らないことは MainActorでやる
94. 16.7ミリ秒未満ですべての処理が終われば ユーザーは認識できない（60FPSの場合）
95. 不必要に色んなものをActorにして 難しくしない
96. 色んなものがActorになると Isola&on Boundaryを越えるときに • 非同期になりawaitが必要になったけど同期で反映したい • Sendableにしないとエラーが出るけど準拠が難しい
97. MainActor外でやるべき処理 • CPUバウンドな重い処理 • • 高頻度で受け取るデータの処理 • • 画像処理、巨大なデータのデコードなど … カメラ等のセンサーからの継続的な入力の解析など
98. ! 遭遇しがちなエラーの対処法
99. 例1: ActorとDispatchQueueの衝突
100. カメラの各フレームを順番にActorで処理 actor CameraProcessor { fileprivate func process( _ sampleBuffer: CMSampleBuffer ) { // 画像処理 } }
101. AVCaptureVideoDataOutputはcallback queueを要求 actor CameraProcessor { private let output: AVCaptureVideoDataOutput private lazy var delegate: VideoOutputDelegate = ... } private func configure() throws { // ... output.setSampleBufferDelegate( delegate, queue: queue // DispatchQueue ) }
102. Delegate nonisolated final class VideoOutputDelegate: NSObject, AVCaptureVideoDataOutputSampleBufferDelegate { private weak let owner: CameraProcessor? } init(owner: CameraProcessor) { self.owner = owner }
103. DelegateメソッドはActorに隔離されていない func captureOutput( _ output: AVCaptureOutput, didOutput sampleBuffer: CMSampleBuffer, from connection: AVCaptureConnection ) { // Call to actor-isolated instance method 'process' // in a synchronous nonisolated context owner?.process(sampleBuffer) // }
104. callback queueをActorのSerial Executorにする actor CameraProcessor { private let queue = DispatchSerialQueue(label: "...") } nonisolated var unownedExecutor: UnownedSerialExecutor { queue.asUnownedSerialExecutor() }
105. 同じqueueをDelegateのcallback queueにする actor CameraProcessor { private let output: AVCaptureVideoDataOutput private lazy var delegate: VideoOutputDelegate = ... } private func configure() throws { // ... output.setSampleBufferDelegate( delegate, queue: queue // DispatchSerialQueue ) }
106. コンパイラは同じqueue上でも認識できない func captureOutput( _ output: AVCaptureOutput, didOutput sampleBuffer: CMSampleBuffer, from connection: AVCaptureConnection ) { // Call to actor-isolated instance method 'process' // in a synchronous nonisolated context owner?.process(sampleBuffer) // }
107. assumeIsolatedだけでは解決しない func captureOutput( _ output: AVCaptureOutput, didOutput sampleBuffer: CMSampleBuffer, from connection: AVCaptureConnection ) { owner?.assumeIsolated { isolatedOwner in // Sending 'sampleBuffer' risks // causing data races isolatedOwner.process(sampleBuffer) // } }
108. 静的なIsola&onのチェックを局所的に外す func captureOutput( _ output: AVCaptureOutput, didOutput sampleBuffer: CMSampleBuffer, from connection: AVCaptureConnection ) { nonisolated(unsafe) let sampleBuffer = sampleBuffer } owner?.assumeIsolated { isolatedOwner in isolatedOwner.process(sampleBuffer) // }
109. ConcurrencyのHeartを理解していれば 何が問題でエラーが起こっているのか 対処の方向性に問題がないか判断できる
110. 例2: ミュータブルクラスを Sendableに準拠させたい
111. 古い設計で解体するのが困難なミュータブルクラス final class OldFatService { var value: Int // ... }
112. ミュータブルなのでSendable準拠できない final class OldFatService: Sendable { // var value: Int // ... }
113. Mutexで可変状態を保護する final class OldFatService: Sendable { // var value: Int { get { _value.withLock { $0 } } set { _value.withLock { $0 = newValue } } } private let _value: Mutex<Int> } // ...
114. Mutexで可変状態を保護する import Synchronization final class OldFatService: Sendable { // var value: Int { get { _value.withLock { $0 } } set { _value.withLock { $0 = newValue } } } private let _value: Mutex<Int> } // ...
115. OSAllocatedUnfairLock (iOS 16, 17) import os final class OldFatService: Sendable { // var value: Int { get { _value.withLock { $0 } } set { _value.withLock { $0 = newValue } } } private let _value: OSAllocatedUnfairLock<Int> } // ...
116. ! どうやって対処法を見つければいいか
117. AIを上手に活用
118. ローカルにcloneすべきリポジトリ AIからローカルでこれらのリポジトリを読めるようにする。 • swiftlang/swift-evolution • swiftlang/swift-migration-guide • swiftlang/swift-book
119. Xcode MCPのDocumenta0onSearch
120. ! おすすめのビルド設定
121. Xcode Build Se,ngs
122. Package.swi+ // swift-tools-version: 6.4 .target( name: "...", swiftSettings: [ .enableUpcomingFeature("NonisolatedNonsendingByDefault"), .enableUpcomingFeature("InferIsolatedConformances"), ] ),
123. @koher • Heart of Swi- 執筆 • Swi- Zoomin' 主催 • Swi- Digest 運営 • ムゲンノゲーム 開発 • Swi- × RealityKitで3Dモデリング →
126. Isola&on Domain = Concurrency Domain
127. What is the difference between isola2on domain and concurrency domain? I'm leaning toward standardizing on "concurrency domain" and upda7ng the migra7on guide to use that term instead of "isola7on 1 domain" — Holly Borla (Mar 2, 2025) 1 h$ps://github.com/swi3lang/swi3-migra9on-guide/issues/130#issuecomment-2692364765
128. Isola&on DomainとConcurrency Domainの 違いは何ですか？ 私は、用語を「Concurrency Domain」に統一し、Migra0on Guide でも「Isola0on Domain」の代わりにそれを使うよう更新する案に 傾いています。 — Holly Borla (Mar 2, 2025)
129. 結局今もIsola&on Domainが優勢
131. Swi$ 6のデフォルト @Observable final class FooModel { // non-isolated func load() async throws { // ... } }
132. Swi$ 6のデフォルト struct FooView: View { @State private var model: FooModel = .init() } func loadFoo() async throws { try await model.load() // }
133. Swi$ 6のデフォルト @Observable final class FooModel { // non-isolated nonisolated(nonsending) func load() async throws { // ... } }
134. NonisolatedNonsendingByDefault @Observable final class FooModel { // non-isolated } func load() async throws { // ... }
135. NonisolatedNonsendingByDefault struct FooView: View { @State private var model: FooModel = .init() } func loadFoo() async throws { try await model.load() // }