Swiftアクターによるミュータブルステートの保護

2つの別々のスレッドが同じミュータブルなステートに同時にアクセスすると、データレースが発生します。データレースは簡単に起きますが、デバッグが難しいことで知られています。コード内のデータへのアクセスを同期化するのに役立つSwiftのアクターを使って、これらのデータレースをどのように止めることができるかを説明します。アクターの仕組みと、アクター間で値を共有する方法をご確認ください。アクターの分離がプロトコル準拠に与える影響について説明します。そして最後に、メインアクターを紹介します。これは、必要なときにコードが常にメインスレッド上で実行されることを保証するための新しい方法です。このセッションを最大限活かしていただくためには、「Swiftのasync/awaitについて」を先にご確認いただくことをお勧めします。

リソース

関連ビデオ

WWDC22

WWDC21

ダウンロード

♪ (Swiftアクターによるミュータブルステートの保護) こんにちはダリオ・レクシンです AppleのSwiftチームのエンジニアです今日はDougと一緒に Swiftのアクタや並列のSwift Appケーションでアクタを使い可変状態を保護する方法をを説明します並列プログラムを書く時に根本的に難しい問題の1つにデータ競合の回避がありますデータ競合は 2つの別のスレッドが同じデータに並列でアクセスする時に発生しそのアクセスの最低1つは書き込みですデータ競合は自明でコンストラクトされますがデバッグは非常に大変ですこれはカウンターをインクリメントして新しい値を返す演算つきの単純なカウンタークラスですでは早速2つの並列タスクからインクリメントしてみましょうこれは悪いアイデアです実行のタイミングにより 1と2または2と1が出てくるでしょうこれは予想できたことでどちらのケースでもカウンターは不変状態に残されることになりますしかしデータ競合を導入したので両方のタスクで0が読まれ 1が書き出されると 1と1が得られますまたは両方のインクリメント演算で return文が発生すれば 2と2ですデータ競合の回避とデバッグは非常に困難です競合を引き起こすデータアクセスはプログラムの様々な場所にある可能性があるので非局所的な推論が必要ですまたオペレーションシステムのスケジューラがプログラム実行のたびに並列タスクをバラバラにインタリーブする可能性があるため非決定性ですデータ競合は共有の可変状態に引き起こされますデータが変わらなかったり複数の並列タスクで共有されないのならそこにデータ競合は発生しませんデータ競合を防ぐ方法の1つに値の意味論を使って共有可変状態を排除するというものがあります値型の変数では可変は全てローカルですさらに値の意味論の型の「let」プロパティは非常に不変なのでバラバラの並列タスクから安全にアクセスできます Swiftは最初から値の意味論を推奨していますプログラムの推論がしやすくまた並列タスクで使用しても安全だからですこの例ではいくつかの値の配列を作成します次に配列を2番目の変数に割り当て配列の各コピーに別の値を加えます最後の両方の配列を出力すると両方のコピーに一緒に初期化された値が含まれていますが各付加価値は付加された別々のコピーにのみ表示されています Swiftの標準ライブラリの型の大部分には辞書やこの例では配列などコレクション型を含む値の意味論がありますさて値の意味論で全てのデータ競合の解決が確立したので次は構造体にすることでカウンターを値型にしますまた値プロパティを修正できるように増分関数をmutatingとする必要がありますカウンターを修正しようとするとカウンターがletなのでコンパイラエラーになり変異できなくなっています変異できるようにするためカウンター変数を varに変えたいのですがカウンターが並列タスクの両方に参照されるので競合状態が残ってしまいます幸運なことにコンパイラがこの非安全なコードのコンパイルをできないようにしてくれますその代わりカウンターを各並列タスク内のローカルな可変変数に割り当てますここで例を実行すると両方の並列タスクに常に1が出力されますしかしコードはこれで競合なしになりましたがこの動作はもう不要です共有可変状態が必要なケースがまだあると示し続けることになります並列プログラムに共有可変プログラムがあると何らかの形の同期によって共有可変状態の並列使用でデータ競合が起こらないないようにする必要があります同期にはアトミックやロックなど低レベルのものからシリアルディスパッチキューなど高レベルなものまで多くの基本命令がありますこれら基本命令のそれぞれには独自の様々な強みがありますが全く同じ大きな弱点があります厳格な原則に基づいて毎回とても丁寧に扱わないとデータ競合が起こるという点ですそこでアクタの出番ですアクタは共有可変状態のための同期メカニズムですプログラムの残りの部分から隔離される独自の状態を持ちますその状態にアクセスするにはアクタを経由するのが唯一の方法ですアクタを経由すればアクタの同期メカニズムにより他のデータがアクタの状態に並列アクセスしないようになりますこれでロックの手動使用やシリアルディスパッチキューと同じ相互排除プロパティが得られますがアクタではこれがSwiftによって根本的に保証されています同期の実行を忘れることもありません Swiftからコンパイラエラーは生成されるからですアクタはSwiftの新しい型の一種で Swiftの全ての型と同じ機能を提供しますプロパティやメソッド初期化子添字などの機能を持ちプロトコルに適合し拡張で増強することができますクラスと同じく参照型ですアクタの目的は共有可変状態を式で表すことだからです実際アクタ型の主な特徴はインスタンスデータをプログラムの他の部分から隔離しデータへの同期アクセスを可能にすることですこうした特別な動作は全てコアとなる考えに従っていますここではカウンターをアクタとして定義しましたこのカウンターへのインスタンスプロパティ値と値を増分し新しい値を返す increment()メソッドがまだありますその違いはアクタのおかげで値が並列アクセスされないことですこのケースでは increment()メソッドは呼び出されるとアクタ上で実行中の他のデータがない状態で完了に達しますこれによりアクタ状態でデータ競合が発生する可能性が確実に排除されますデータ競合の例に戻ってみましょう同じカウンターの増分を試みている2つの並列タスクがありますアクタの内部同期メカニズムは一方の増分呼び出しの完了がもう一方を開始前に行われるようにしますそれで1と2または2と1が得られます両方とも有効な並列実行だからですしかしアクタの内部同期がアクタ状態のデータ競合の可能性を排除したため同じ値を二度得たり値のスキップが起こったりすることはありません並列タスクの両方がカウンターを同時に増分しようとした時に何が起こるか考えてみましょう一方がまず到着しもう一方はターンを待つことになりますしかし2番目のタスクがアクタでのターンを待つようにするにはどうすればよいでしょうか？そのメカニズムが Swiftにあります外からアクタを操作する場合非同期で行うことになりますアクタがビジーだと実行中のCPUで他の有用な仕事が行われるようコードが停止されますアクタがまたフリーになるとコードを起こして実行を再開し呼び出しがアクタで実行されるようになりますこの例のawaitキーボードはアクタへの非同期呼び出しでこのような停止が起こる可能性を示唆しています不要な遅いリセット演算を追加して反例をもう少し拡大してみましょうこの演算では値が 0に戻っていてその後呼び出しが適切な回数を増分し新しい値のカウンターが得られますこのresetSlowly()メソッドはカウンターアクタ型の拡張で定義されているためアクタの中にありますつまりアクタ状態に直接アクセスできカウンター値を0にリセットしますまた増分呼び出しの中などアクタの他のメソッドも同期で呼び出しますアクタで実行中だと既に分かっているので awaitの必要もありませんこれはアクタにとって重要なプロパティですアクタの同期コードは中断されることなく常に完了に達しますそのためアクタ状態のコンカレンシーの効果を検討する必要なく同期コードを連続で推論することができます非同期コードを中断なく実行できることを強調してきましたがアクタはお互いまたはシステムの他のコードと相互作用することがあります非同期コードとアクタについて少しお話ししますでもまずはもっと良い例が必要ですここでは画像ダウンローダーアクタを構築しています他のサービスから画像をダウンロードするものですまたダウンロードした画像をキャッシュに保存し同じ画像が何度もダウンロードされないようにしますロジカルフローはとても単純でキャッシュをチェックして画像をダウンロードし戻る前に画像をキャッシュに記録しますこれはアクタなのでコードに低レベルのデータ競合がなく画像をいくらでも並列でダウンロードできますアクタの同期メカニズムでキャッシュインスタンスプロパティにアクセスするコードが実行されるのは一度に1つのタスクのみと保証されるためキャッシュが破損することはありませんとはいえここのawaitキーボードは非常に重要なことを伝えています awaitがいつ起こったかを問わず await関数はこの時点で停止されるということです CPUが解放されプログラムのその他のコードが実行可能となり全体のプログラム状態がその影響を受けます関数が再開されると全体のプログラム状態が替わります awaitの後に待機しないかもしれない awaitに先立って状態について推測しないようにしましょう同じ画像を同時にフェッチ使用する 2種類の並列タスクがあるとします最初のものはキャッシュエントリがないと判断するとサーバーから画像のダウンロードを開始しダウンロードに時間がかかるのでしばらく停止します最初のタスクが画像をダウンロード中同じURLで新しい画像がサーバーにデプロイされると 2番目の並列タスクがそのURLから画像をフェッチしようとします今回もキャッシュエントリがないようです 1番目のダウンロードがまだ完了していなく 2番目のダウンロードを開始したからですまたダウンロード完了中に停止されていますしばらくしてダウンロードのいずれかで恐らく1番目だとしてそこでタスクがそのアクタでの実行を再開しますキャッシュを追加し結果として猫の画像を返しますさて 2番目のタスクのダウンロードも完了し再起されます取得した悲しい猫の画像でキャッシュの同じエントリを上書きしていますキャッシュに画像が既に追加されていても同じURLから別の画像が得られますこれはびっくりです期待していたのは画像をキャッシュすると同じURLから同じ画像を取得しそのためユーザーインターフェイスが少なくともキャッシュを手動で消去するまでは一貫していることですでもここではキャッシュされた画像が変わっています低レベルのデータ競合はありませんが await全体の状態で推測をしたのでバグの可能性につながりましたこれを修正するには await後の推測を確認します再開時にキャッシュにエントリが既にあれば元のバージョンを残し新しいものは捨てますもっと良いのは冗長なダウンロードを完全に避けることでしょうそのソリューションを関連動画で説明していますアクタ再入可能性でデッドロックが防がれ前進が保証されますが各await全体で推測の確認が求められます再入可能性に備えるためには同期コード内でアクタ状態の変異を行います同期関数内で行うのが理想です全ての状態変更がきちんとカプセル化されるからです状態変更を行うとアクタが一時的に矛盾状態になります awaitの前に一貫性を回復するようにしましょうまたawaitが停止ポイントになる可能性もありますコードが停止されるとコードが再開される前にプログラムなどが進行していきます時計やタイマーなどグローバル状態に行った推測は awaitの後に確認する必要がありますそれではこれからDougがアクタ隔離についてお話しますありがとう Dario アクタ隔離はアクタタイプの動作としては根本的なものです Darioがアクタの外からのアクタ隔離について Swift言語モデルでアクタ隔離がどう保証されているか説明しましたこのセクションではアクタ隔離がプロトコル適合性やクロージャクラスなど他の言語機能とどう相互作用するかに触れますアクタは他のタイプと同様プロトコルの必要条件を満たせる限りプロトコルに適合することができます例えば LibraryAccount アクタを Equatableプロトコルに適合させてみましょう静的な透過性メソッドは ID番号に基づいて 2つの図書館アカウントを比較しますメソッドが静的なのでセルフインスタンスはなくアクタに隔離されていませんその代わりアクタタイプに 2つのパラメーターがありこの静的メソッドは 2つの圏外にあります実装がアクタの不可変状態にアクセスしているだけなのでこれは問題ありません例をもっと掘り下げ図書館のアカウントを Hashableプロトコルに適合させてみましょうそのためにはhash(into)演算をこのように実装する必要がありますしかしSwiftコンパイラからこの適合は許可されていないとエラーが出ます何があったのでしょうか Hashableにこういう風に適合するというのはこの関数がアクタ外から呼び出されるということですが hash(into)は非同期ではありませんそのためアクタの隔離を維持できないのですこれはメソッドを非隔離にすることで直せます非隔離とはこのメソッドがアクタ外にあるとして扱われても構文的にはアクタ上で記述されるということですこれはHashableプロトコルから同期必要条件を満たすことができるという意味です非隔離のメソッドはアクタ外にあるとして扱われるのでアクタ上で可変状態を参照できません不可変のID番号を参照しているのでこのメソッドは問題ありません booksOnLoan配列など別のもので値変換する場合エラーになります外からの可変状態へのアクセスはデータ競合を許可するものだからです以上プロトコルの適合性についてです次はクロージャについてですクロージャはちょっとした関数で 1つの関数内で定義され後になって呼び出すために別の関数に渡されるものです関数と同様クロージャもアクタ隔離型または非隔離ですこの例では貸し出し中の本からいくつか読み込み読んだページの総数を返します reduceの呼び出しには読み込みを行うクロージャが関係していますこのreadSome呼び出しには awaitはありませんそれはこのクロージャがアクタ隔離型関数「read」内で形成されそれ自体アクタ隔離型だからですリダクション演算が同期実行され並列アクセスを引き起こしかねない他のスレッドにクロージャを逃がすことはできないのでこれは安全だと分かっていますでは少し趣向を変えてみましょう今は読む時間がないので後で読むとしますここでデタッチされたタスクを作りますデタッチされたタスクはクロージャをアクタの他の仕事と並列で実行します従ってクロージャがアクタに乗れないかデータ競合が起こることになりますだからこのクロージャはアクタに隔離されていません read()メソッドを呼び出したい時には awaitに示される通り非同期でしなければなりませんコードがアクタの内外で実行される場合それぞれのコードのアクタ隔離についてはここまでです次はアクタ隔離とデータについてお話しします図書館アカウントの例では実際の本のタイプにはあえて触れませんでした構造体のような値型だと思っていますこれは良い選択です図書館アカウントアクタのインスタンスの全ての状態は自己完結型だからです早速このメソッドを呼び出して読む本を無作為に選ぶと読める本を一部得られます本に行った変更がアクタに影響を与えることやその逆はありませんしかし本をクラスにするとちょっと違ったことになります図書館アカウントアクタは本のクラスのインスタンスを参照しますそこ自体では問題ではありませんしかし無作為に本を選ぶメソッドを呼び出したらどうなるのでしょうか？ここには参照情報つまりアクタの可変情報がありこれはアクタの外で共有されていますこれだとデータ競合の可能性がありますでは本のタイトルを更新すると修正がアクタからアクセス可能な状態で起こります visit()メソッドはアクタ上にないので修正がデータ競合になってしまいます値型とアクタは両方とも安全に並列利用できますがクラスにはまだ問題があります問題なく並列利用できるタイプは Sendableです Sendableタイプではその値を様々なアクタで共有することができます値をある場所から別の場所にコピーし両方の場所で値のコピーを互いに干渉せず修正できる場合それはSendableと言えます Darioが先程話した通り各コピーが独立しているので値型はSendableですアクタタイプも Sendableです可変状態へのアクセスを同期するからですクラスもSendableになりえますが注意深く実装された場合のみです例えばクラスやその全てのサブクラスに不可変データしかない場合は Sendableと言えますまたはクラスの内部で同期が行われる場合例えば安全な並列アクセスを可能にするロックでは Sendableになりえますしかしクラスのほとんどはこのどちらでもなく Sendableになれません関数は必ずしも Sendableではないのでアクタ間で安全にパスできる関数のために新しい関数タイプがありますこれについては後でまた触れますアクタはいや並列コードは全て Sendableタイプの観点から主に通信すべきです Sendable型はデータ競合からコードを守りますこれはSwiftが最終的に静的にチェックを始めるプロパティですその点ではアクタ境界に non-Sendable型を渡すエラーとなります型がSendableだとどのように知るのでしょうか Sendableはプロトコルなので型はSendableに他のプロトコルと同じ方法で適合すると述べますするとSwiftが型がSendableとして成立しているかチェックします Nookの構造体は保存されたプロパティが全て Sendable型であれば Sendableとなります一方Authorは実際にクラスでつまり著者の配列は Sendableではありません Swiftはコンパイラエラーを生成し BookがSendableになれないと示します総称型では Sendableであるかどうかは総称因数による場合があります Conditional Conformance を使えば適切な時にSendableを伝搬することができます例えばペアの型は両方の総称引数がSendable の時だけSendableになります同じアプローチが Sendableタイプの配列を Sendableそのものだと結論付けるときにも使われます並列で共有して問題ない値型には Sendable適合性の導入をおすすめしますそうした型をアクタ内で使うと Swiftがアクタ中で Sendableの実行を始めコードの準備が整います関数そのものも Sendableになりえますつまり関数の値をアクタ中に渡しても安全だということですこれはクロージャにとっては特に重要ですクロージャがデータ競合を防ぐのを制限するからです例えば Sendableクロージャは可変のローカル変数をキャプチャできませんローカル変数のデータ競合を引き起こすからですクロージャがキャプチャするものは全てクロージャがnon-Sendable型をアクタ境界中に移すのに使われないよう Sendableである必要がありますそして最後に同期Sendableクロージャはアクタを外から実行されるようコードに許可するためアクタ隔離型にはなれませんこの動画では Sendableクロージャという考えをよく使いましたデタッチされたタスクを作成する演算にはここで関数型に @Sendableで書かれた Sendable関数が使われます最初のほうの反例を覚えているでしょうか値型のカウンターを構築しようとしていましたねそして同時に2つのクロージャから修正しようとしていましたこれは可変ローカル変数ではデータ競合となりますしかしデタッチされたタスクのクロージャはSendableなので Swiftはここでまだエラーを出しています Sendableの関数型は並列実行がどこで起こる可能性があり結果データ競合を防ぐために用いられますこれは先程見たもう1つの例ですデタッチされたタスクのクロージャはSendableなのでアクタに隔離してはいけないと分かっています従って相互作用は非同期でなくてはなりません Sendable型とクロージャにより可変状態がアクタ中で共有されないことをチェックしアクタの隔離が維持され並列で修正されるようにできますさてアクタの型やそれがプロトコルやクロージャ Sendable型と相互作用する方法をお話してきましたもう1つ触れるべきアクタがありますメインアクタと呼んでいる特別なものです Appを構築中メインスレッドについて考える必要がありますコアなユーザーインターフェイスのレンダリングの発生や UIイベントの処理はここで起こるからです UIに関連する演算は通常メインスレッドから行われる必要がありますしかし全部の作業をメインスレッドでしたくはないものですメインスレッド上で作業をし過ぎると入力・出力演算が遅くなったりサーバーとの相互作用がブロックされたりし UIがフリーズしますそのためメインスレッドが UIに相互作用する時にはメインスレッドでの作業に注意し計算コストが高いか待ち時間の高い演算のためにメインスレッドを速く抜ける必要がありますさて可能な時にメインスレッドを抜けたら DispatchQueue.main.async をコードで呼び出しメインスレッドで実行すべき特定の演算がある場合ですメカニズムの詳細から戻るとこのコードの構造には若干見覚えがありますね実際メインスレッドとの相互作用はアクタとの相互作用に非常に似ていますメインスレッドで既に実行中と知っているなら UI状態に安全にアクセスし更新できますメインスレッドで実行中でなければ非同期で相互作用する必要がありますこれこそがアクタの仕組みですメインスレッドを記述する特別なアクタをメインアクタと呼ぶのですメインアクタはメインスレッドを表すアクタなのです通常のアクタとは 2つの点で大きく異なりますまずメインアクタがメインディスパッチキュー経由で同期の全てを行いますつまりランタイムの観点から言うと DispatchQueue.main を使うことでメインアクタは互換可能になります次にメインスレッド上に置かれるべきコードとデータは Swift UIやAppleKit UIKitやその他システムワークなど色々なものに入っていますご自身のビューやビューコントローラーデータモデルのUI関連部分で広く使えます Swiftの並行性によりメインアクタの属性でそれがメインアクタで実行されなければならないと宣言することができますここで確認した演算は完了しているので常にメインスレッドで実行されますメインアクタの外から呼び出す場合その呼び出しがメインスレッドで非同期的に行われるまで待機しますメインスレッドで実行しなければならないコードをメインアクタ―とすると DispatchQueue.main をいつ使うかについて推論する必要は皆無です Swiftはこのコードが常にメインスレッドで実行されるようにします型もメインアクタ上に置かれよってメンバー全てとそのサブクラスがメインアクタに置かれますこれはUIと相互作用しなければならないコードベース部分では便利ですほとんど全てをメインスレッドで実行しなければならないからです個々のメソッドは非隔離キーワード経由で通常のアクタで慣れているのと同じルールでオプトアウトできます UI関連のタイプや演算にメインアクタを使い他のプログラムの状態に独自のアクタを導入することで Appが安全で並行性を正しく使うよう構築できますこのセッションではアクタが可変状態を並列アクセスから守っている方法を説明しましたつまりアクタ隔離を使ったり連続実行を行うためにアクタの外から非同期アクセスを要求したりしていますご自身のSwiftコードでアクタを使い安全な並列抽出を構築しましょうご自分のアクタを非同期アクタに実装するには再入可能性を常に念頭に入れてデザインしましょうコードにawaitがあると推論が無効になってしまいます値型とアクタは共同でデータ競合を排除します独自の同期を処理しないクラスや共有可変状態を実行する他のnon-Sendable型には注意してください最後にコードでは UIと相互作用するメインアクタを使いメインスレッド上にあるべきコードが常にメインスレッドにあるようにしましょうご自身のAppでのアクタの使い方について詳細は Swift並行性のためのApp更新についてのセッションをご覧くださいまたアクタなどSwift 並行性モデルの実装については「Behind the scenes」セッションをご覧くださいアクタはSwift並行性モデルの主要な部分です async/awaitと動作し正確で効果的な並列プログラムを構築しやすくする構造化された並行性です皆さんがどんなものを構築するか楽しみにしています ♪

0:42 - Data races make concurrency hard

class Counter {
    var value = 0

    func increment() -> Int {
        value = value + 1
        return value
    }
}

let counter = Counter()

Task.detached {
    print(counter.increment()) // data race
}

Task.detached {
    print(counter.increment()) // data race
}

2:20 - Value semantics help eliminate data races

var array1 = [1, 2]
var array2 = array1

array1.append(3)
array2.append(4)

print(array1)        // [1, 2, 3]
print(array2)        // [1, 2, 4]

2:59 - Sometimes shared mutable state is required

struct Counter {
    var value = 0

    mutating func increment() -> Int {
        value = value + 1
        return value
    }
}

let counter = Counter()

Task.detached {
    var counter = counter
    print(counter.increment()) // always prints 1
}

Task.detached {
    var counter = counter
    print(counter.increment()) // always prints 1
}

5:23 - Actor isolation prevents unsynchronized access

actor Counter {
    var value = 0

    func increment() -> Int {
        value = value + 1
        return value
    }
}

let counter = Counter()

Task.detached {
    print(await counter.increment())
}

Task.detached {
    print(await counter.increment())
}

7:51 - Synchronous interation within an actor

extension Counter {
    func resetSlowly(to newValue: Int) {
        value = 0
        for _ in 0..<newValue {
            increment()
        }
        assert(value == newValue)
    }
}

9:02 - Check your assumptions after an await: The sad cat

actor ImageDownloader {
    private var cache: [URL: Image] = [:]

    func image(from url: URL) async throws -> Image? {
        if let cached = cache[url] {
            return cached
        }

        let image = try await downloadImage(from: url)

        // Potential bug: `cache` may have changed.
        cache[url] = image
        return image
    }
}

11:50 - Check your assumptions after an await: One solution

actor ImageDownloader {
    private var cache: [URL: Image] = [:]

    func image(from url: URL) async throws -> Image? {
        if let cached = cache[url] {
            return cached
        }

        let image = try await downloadImage(from: url)

        // Replace the image only if it is still missing from the cache.
        cache[url] = cache[url, default: image]
        return cache[url]
    }
}

11:59 - Check your assumptions after an await: A better solution

actor ImageDownloader {

    private enum CacheEntry {
        case inProgress(Task<Image, Error>)
        case ready(Image)
    }

    private var cache: [URL: CacheEntry] = [:]

    func image(from url: URL) async throws -> Image? {
        if let cached = cache[url] {
            switch cached {
            case .ready(let image):
                return image
            case .inProgress(let task):
                return try await task.value
            }
        }

        let task = Task {
            try await downloadImage(from: url)
        }

        cache[url] = .inProgress(task)

        do {
            let image = try await task.value
            cache[url] = .ready(image)
            return image
        } catch {
            cache[url] = nil
            throw error
        }
    }
}

13:30 - Protocol conformance: Static declarations are outside the actor

actor LibraryAccount {
    let idNumber: Int
    var booksOnLoan: [Book] = []
}

extension LibraryAccount: Equatable {
    static func ==(lhs: LibraryAccount, rhs: LibraryAccount) -> Bool {
        lhs.idNumber == rhs.idNumber
    }
}

14:15 - Protocol conformance: Non-isolated declarations are outside the actor

actor LibraryAccount {
    let idNumber: Int
    var booksOnLoan: [Book] = []
}

extension LibraryAccount: Hashable {
    nonisolated func hash(into hasher: inout Hasher) {
        hasher.combine(idNumber)
    }
}

15:32 - Closures can be isolated to the actor

extension LibraryAccount {
    func readSome(_ book: Book) -> Int { ... }
    
    func read() -> Int {
        booksOnLoan.reduce(0) { book in
            readSome(book)
        }
    }
}

16:29 - Closures executed in a detached task are not isolated to the actor

extension LibraryAccount {
    func readSome(_ book: Book) -> Int { ... }
    func read() -> Int { ... }
    
    func readLater() {
        Task.detached {
            await read()
        }
    }
}

17:15 - Passing data into and out of actors: structs

actor LibraryAccount {
    let idNumber: Int
    var booksOnLoan: [Book] = []
    func selectRandomBook() -> Book? { ... }
}

struct Book {
    var title: String
    var authors: [Author]
}

func visit(_ account: LibraryAccount) async {
    guard var book = await account.selectRandomBook() else {
        return
    }
    book.title = "\(book.title)!!!" // OK: modifying a local copy
}

17:39 - Passing data into and out of actors: classes

actor LibraryAccount {
    let idNumber: Int
    var booksOnLoan: [Book] = []
    func selectRandomBook() -> Book? { ... }
}

class Book {
    var title: String
    var authors: [Author]
}

func visit(_ account: LibraryAccount) async {
    guard var book = await account.selectRandomBook() else {
        return
    }
    book.title = "\(book.title)!!!" // Not OK: potential data race
}

20:08 - Check Sendable by adding a conformance

struct Book: Sendable {
    var title: String
    var authors: [Author]
}

20:43 - Propagate Sendable by adding a conditional conformance

struct Pair<T, U> {
    var first: T
    var second: U
}

extension Pair: Sendable where T: Sendable, U: Sendable {
}

24:19 - Interacting with the main thread: Using a DispatchQueue

func checkedOut(_ booksOnLoan: [Book]) {
    booksView.checkedOutBooks = booksOnLoan
}

// Dispatching to the main queue is your responsibility.
DispatchQueue.main.async {
    checkedOut(booksOnLoan)
}

25:01 - Interacting with the main thread: The main actor

@MainActor func checkedOut(_ booksOnLoan: [Book]) {
    booksView.checkedOutBooks = booksOnLoan
}

// Swift ensures that this code is always run on the main thread.
await checkedOut(booksOnLoan)

26:21 - Main actor types

@MainActor class MyViewController: UIViewController {
    func onPress(...) { ... } // implicitly @MainActor

    nonisolated func fetchLatestAndDisplay() async { ... } 
}

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。