Swiftの並行処理: 舞台裏

Swiftの並行処理: 舞台裏

Swiftの並行処理の詳細を深く掘り下げて、データレースやスレッドの爆発が生じるリスクを低減すると同時にパフォーマンスを向上させるために、Swiftがどのような役割を果たすのかを明らかにします。SwiftのタスクのGrand Central Dispatchとの相違点、新しい協調スレッドモデルのしくみ、そしてAppの最高のパフォーマンスを確保する方法を探ります。このセッションを最大限活かしていただくためには、事前に「Swiftのasync/awaitについて」、「Swiftにおける構造化並行処理」、「Swiftアクターによるミュータブルステートの保護」を先にご確認いただくことをお勧めします。

リソース
- The Swift Programming Language: Concurrency
- - HDビデオ
  - SDビデオ
関連ビデオ

WWDC23
WWDC22
- Swiftの並行処理でデータ競合を排除する
- Swiftの並行処理を視覚化して最適化する
WWDC21
WWDC17
- Modernizing Grand Central Dispatch Usage
WWDC16
- Concurrent Programming With GCD in Swift 3
ダウンロード

♪ (Swiftの並行処理: 舞台裏) こんにちは「Swiftの並行処理: 舞台裏」へようこそ私の名前はRokhini Prabhu Darwin Runtimeチームに勤務しています今日私の同僚のVarunと私は Swiftの並行処理に関する根本的なニュアンスのいくつかについてお話することにとてもワクワクしています
これはSwiftの並行処理：Concurrency について以前の講演を踏まえた上級者向けの講演です async/await 構造化並行処理およびアクターの概念に精通していない場合はこちらのお話をまずお聞きになることをお勧めします Swift並行処理に関する以前の講演で今年Swiftに備わるさまざまな言語機能およびその使用方法について学習しましたこの講演では言語の安全性だけでなくパフォーマンスと効率性のためにこれらの基本要素がそのように設計されている理由をより深く理解しますご自身のAppでSwiftの並行処理を実験して採用しながらこの講演でSwiftの並行処理について推論する方法と Grand Central Dispatchなどの既存のスレッドライブラリとのインターフェース方法についてのより良いメンタルモデルを提供することを望んでいます今日はいくつかの点についてお話します最初にSwiftの並行処理の背後にあるスレッドモデルについて説明し Grand CentralDispatchと対比します並行処理言語機能を利用して Swiftの新しいスレッドプールを構築しそれによってパフォーマンスと効率を向上させる方法について説明します最後にこのセクションではコードをSwiftの並行処理を使用するように移植するときに留意する必要がある考慮事項について説明します次にVarunがアクターを介した Swift並行処理の同期について説明しますアクターが内部でどのように機能するかシリアルディスパッチキューなどすでに使い慣れている既存の同期基本要素とどのように比較するかそして最後にアクターを使用してコードを作成するときに留意すべき点について説明します今日はお話しすることが多くあるのですぐ始めましょうスレッドモデルに関する今日のディスカッションでは Grand Central Dispatchなどの今日利用可能なテクノロジーで記述されたサンプルAppを確認することから始めます次にSwiftの並行処理で書き直したときに同じAppがどのように機能するかを確認します自分のニュースフィードリーダーAppを書きたいとしましょう私のAppの高レベルコンポーネントが何であるかについて話しましょう私のAppにはユーザーインターフェイスを駆動するメインスレッドがありますユーザーが登録しているニュースフィードを追跡するデータベースがあり最後にフィードから最新のコンテンツを取り込むためのネットワークロジックを処理するサブシステムがあります Grand Central Dispatchキューを使用してこのAppを構成する方法を考えてみましょうユーザーが最新のニュースを見ることを要求したとしましょうメインスレッドではユーザーイベントジェスチャを処理しますここからデータベース操作を処理するシリアルキューに dispatch_async() をリクエストしますこの理由は2つありますまず作業を別のキューにディスパッチすることで大量の作業が発生するのを待っている間でもメインスレッドがユーザー入力に応答し続けることができるようにします次にシリアルキューが相互排斥を保証するためデータベースへのアクセスが保護されますデータベースキューにいる間ユーザーがサブスクライブしたニュースフィードを繰り返し処理しそれぞれについて URLSessionへのネットワークリクエストをスケジュールしてそのフィードのコンテンツをダウンロードしますネットワークリクエストの結果が届くと並行キューであるデリゲートキューで URLSessionコールバックが呼び出されます各結果の完了ハンドラーでこれらの各フィードからの最新のリクエストでデータベースを同期的に更新し将来の使用のためにデータベースをキャッシュします最後にメインスレッドを起動して UIを更新しますこれはそのようなAppを構築するための完全に合理的な方法のようですリクエストの処理中にメインスレッドをブロックしないようにしましたまたネットワークリクエストを同時に処理することでプログラムに固有の並列処理を利用しましたネットワークリクエストの結果を処理する方法を示すコードスニペットを詳しく見てみましょうまずニュースフィードからダウンロードを実行するためのURLSessionを作成しましたここでお分かりのようにこの URLSession の delegateQueue を concurrentQueue に設定しました次に更新が必要なすべてのニュースフィードを繰り返し処理しそれぞれについて URLSession で dataTask をスケジュールしますデリゲートキューで呼び出される dataTask の完了ハンドラーでダウンロードの結果を逆シリアル化し記事にフォーマットします次にフィードの結果を更新する前にデータベースキューに対して dispatch_sync() を実行しますここではかなり簡単なことを行うためにいくつかの直列的なコードを記述したことがわかりますがこのコードにはいくつかの隠れた出力上の落とし穴がありますこれらのパフォーマンスの問題についてさらに理解するにはまずGCDキューでの作業を処理するためにスレッドを起動する方法を掘り下げる必要があります Grand Central Dispatchでは作業がキューに入れられるとシステムはその作業項目を処理するためのスレッドを起動します並行キューは一度に複数の作業項目を処理できるためすべてのCPUコアが飽和状態になるまでシステムは複数のスレッドを起動しますただしスレッドがブロックされここの最初のCPUコアで見られるように並行キューで実行する作業がさらにある場合 GCDは残りの作業項目をさばくためにより多くのスレッドを起動しますこの理由は2つありますまずプロセスに別のスレッドを与えることで各コアがいつでも作業を実行するスレッドを持ち続けることを保証できますこれによりAppに継続的レベルの並行処理が提供されます次にブロックされたスレッドはさらに進行する前にセマフォなどのリソースを待機している可能性があります作業を継続するために立ち上げられた新しいスレッドキューにあると最初のスレッドが待機しているリソースのブロックを解除できる場合があります GCDでのスレッドの起動について少し理解できたので戻ってニュースAppでのコードのCPU実行を見てみましょう Apple Watchのような２コアデバイスでは GCDは最初に２つのスレッドを起動してフィードの更新結果を処理しますスレッドがデータベースキューへのアクセスをブロックするとネットワークキューでの作業を継続するためにさらに多くのスレッドが作成されます次にCPUはさまざまなスレッド間の白い縦線で示されているようにネットワーク結果を処理するさまざまなスレッド間でコンテキストスイッチを実行する必要がありますこれは当社のニュースAppでは非常に多くのスレッドが発生する可能性があることを意味しますユーザーが更新する必要のある100のフィードを持っている場合ネットワーク要求が完了するとそれらの各URLデータタスクの同時実行キューに完了ブロックができます GCDは各コールバックがデータベースキューでブロックされるとより多くのスレッドを起動するため Appに多数のスレッドが含まれることになりますあなたは当社のAppにたくさんのスレッドがあることの何がそんなに悪いのかと疑問に思うかもしれません Appに多数のスレッドがあるということは CPUコアよりも多くのスレッドでシステムがオーバーコミットされていることを意味します 6つのCPUコアを搭載した iPhoneを考えてみましょうニュースAppに処理が必要な100のフィード更新がある場合これはコアの16倍のスレッドで iPhoneをオーバーコミットしたことを意味しますこれは私たちが「スレッド爆増」と呼ぶ現象です以前の WWDCで App内でのデッドロックの可能性を含む関連するリスクについての詳細についてお話ししましたスレッド爆増ではメモリ及びスケジューリングのオーバーヘッドも発生しすぐには顕在化しない場合がありますこれをさらに詳しく見ていきましょう当社のニュースAppを振り返るとブロックされた各スレッドが貴重なメモリとリソースを保持したまま再び実行するのを待っていますブロックされた各スレッドにはスレッドを追跡するためのスタックと関連するカーネルデータ構造がありますこれらのスレッドの一部は実行中の他のスレッドが必要とするロックを保持している可能性がありますこれは待機スレッドが占有する多数のリソースとメモリですスレッド爆増の結果によるより大きなスケジューリングコストもあります新しいスレッドが立ち上がると同時に CPU が新しいスレッドを実行し始めるために古いスレッドから切り替えるため完全なスレッドコンテキストスイッチを行う必要がありますブロックされたスレッドが再び実行可能になるとスケジューラーはCPU上のスレッドをタイムシェアしてすべてのスレッドが進行できるようにする必要がありますスレッドのタイムシェアリングはそれが数回発生する場合は問題ありませんこれが並行処理の力ですただしスレッド爆増がある場合限られたコア数のデバイスで数百のスレッドをタイムシェアすると過度のコンテキストスイッチングが発生する場合がありますスレッドのスケジューリングの待ち時間がそれらが実行する有用な作業の量に勝るため CPUの実行効率も低下します私たちがこれまで見た通りGCDキューで Appを作成する際これらのスレッドに関する微妙な違いを見逃しがちであるためパフォーマンスが下がりオーバーヘッドが大きくなりますこの経験を踏まえ Swift は言語への並行処理を設計する際異なるアプローチを行いました当社はSwiftの並行処理をパフォーマンスと効率にも気を配って構築したため Appは制御可能で構成化され安全な並行処理を享受できます SwiftではAppの実行モデルをスレッド数とコンテキストスイッチングが多い現在のモデルからこれに変更したいと考えていますこちらでは２コアシステムで実行する場合スレッドは２本しかなくスレッドのコンテキストスイッチがありませんブロックされたスレッドは全て無くなり代わりに作業の再開をトラッキングするための continuation「続行」として知られる軽量オブジェクトがあります Swift並行処理の下でスレッドが作業を実行する際完全なスレッドコンテキストスイッチングを行う代わりに continuationの間で切り替えますこれは代わりに関数呼び出しのコストのみを支払うという意味ですそのためSwift並行処理で求めるランタイムの動作は CPU コアと同じ数のスレッドのみを作成しスレッドがブロックされた時はワークアイテムを安価かつ効率的に切り替えることができるようにすることです皆様には推論が容易で安全で制御された並行処理を提供する直線的なコードを書けるようになっていただきたいと思います私たちが求めるこの動作を実現するためにオペレーティングシステムにはスレッドがブロックせず言語がそれをもたらすことができる場合のみに可能な実行時の取決めが必要です Swiftの並行処理モデルとその周辺のセマンティクスはこの目標を念頭に置いて設計されていますランタイムとのコントラクトを維持できるようにする Swiftの2つの言語レベルの機能について詳しく説明したいと思います１つ目は await のセマンティクスに由来し２つ目は Swiftランタイムでのタスクの依存関係の追跡に由来します当社の事例のニュースAppでこれらの機能を考えてみましょうこれは先ほどお話ししたニュースフィードの更新結果を処理するコードスニペットです Swift並行処理プリミティブで記述した場合このロジックがどのようになるか見てみましょうまずはヘルパー関数の非同期実行の作成から始めますその後並行処理ディスパッチキューでネットワークリクエストの結果を処理する代わりにタスクグループを使用して並行処理を管理します本タスクグループにおいて当社は更新される必要があるタスクグループでは更新が必要なフィードごとに子タスクを作成します各子タスクは共有 URLSession を使用してフィードのURLからダウンロードを実行しますその後ダウンロード結果をデシリアライズしそれらを記事にフォーマットし最終的に非同期関数を呼び出してデータベースを更新しますここで非同期関数を呼び出す際 await キーワードで注釈を付けます「Swiftのasync/awaitについて」の講義で await は非同期の待機であることを学びましたそれは非同期関数からの結果を待っている間現行のスレッドをブロックしません代わりに関数は中断されスレッドは他のタスクを実行するために開放されますこれはどのように起こりますか？どのようにスレッドを放棄しますか？私の同僚のVarunがこれを可能にするために Swift ランタイムの内部で何が行われるかを説明しますありがとう Rokhini 非同期関数の実装方法に飛び込む前に非同期関数がどのように機能するかについて簡単に復習しましょう実行中のプログラムの全スレッドにはそれぞれ一つのスタックがありそれを使用して関数呼び出しの状態を保存しますとりあえずひとつのスレッドに焦点を当てますスレッドが関数呼び出しを実行する際新規フレームがスタックにプッシュされますこの新規に作成されたスタックフレームはローカル変数リターンアドレスその他の必要な情報を格納するために関数が使用します関数が実行を終了してリターンすればそのスタックフレームがポップされますでは非同期関数を考えてみましょうスレッドが updateDatabase 関数から Feed の addメソッドを呼び出したとしますこの段階で最新のスタックフレームは「add」用になりますこのスタックフレームには「停止点」以降で不要なローカル変数を保存します addの本体には「停止点」があり await とマークされていますローカル変数idとarticleは定義された後すぐに forループの本体で使用され間に中断ポイントはありませんよってそれらはスタックフレームに格納されますさらにヒープには２つの非同期フレームがあり一つは updateDatabase 用で一つは add 用です非同期フレームには停止ポイントで利用可能でなければならない情報を保存します newArticles の引数は待機前に定義されていますが待機の後にも使用できる必要がありますこれは add 用の非同期フレームが newArticles をトラックすることを意味しますスレッドが実行を続行すると save 関数が実行を開始する際 add 用のスタックフレームが save 用のスタックフレームに置き換えられます新しいスタックフレームを追加する代わりにトップのスタックフレームが置き換えられますこれは将来必要になる変数が非同期フレームのリストにすでに格納されているためです save 関数は使用する非同期フレームも取得します記事をデータベースに保存する間スレッドがブロックされる代わりにいくつかの有用な作業を行うことができるほうが良いです save関数の実行が停止されるとしますスレッドはブロックされる代わりにその他の作業を行うために再使用されます一時停止ポイントで維持されるすべての情報はヒープに格納されるため後の段階で実行を継続するために使用できますこの非同期フレームのリストが継続 continuation の実行時の姿ですしばらくしてデータベースリクエストが完了し一部のスレッドが解放されたとしますこれは前と同じスレッドかもしれませんし異なるスレッドかもしれません save 関数がこのスレッドで実行を再開するとします実行が終了し ID をリターンすると save のためのスタックフレームは再び add のためのスタックフレームと入れ替わりますその後スレッドは zip の実行を開始します２つの配列のジップは同期の処理なので新規のスタックフレームを作成します Swift の continue はオペレーティングシステムのスタックを使用するため非同期および同期 Swift コードの両方とも効果的に C および Objective-C を呼び出せますさらにC および Objective-C コードは効果的に同期 Swift コードを呼び出し続けることができます zip 関数が終了するとスタックフレームはポップされ実行が続行されますここまでスレッドのリソースを解放して他の作業を実行しながら効率的な一時停止と再開を保証するために await がどのように設計されているか説明してきました次にRokhiniが２つ目の言語の機能であるタスク間の依存性の実行時の追跡について説明しますありがとう Varun 先ほど説明された通り関数は待機時に continuation に分割でき潜在的な停止点としても知られますこの場合 URLSessionのdataタスクは非同期関数でその後の残りの作業は continuation です continuation は非同期関数が完了した後でのみ実行できますこれは Swift 並行処理ランタイムによりトラッキングされる依存性です同様にタスクグループ内で親タスクが複数の子タスクを作成した場合それらの子タスクのそれぞれは親タスクが進行する前に完了する必要がありますこれはタスクグループのスコープによりコードで表される依存性であるため Swift コンパイラとランタイムに明示的に認識されます Swift ランタイムに認識されている継続又は子タスクのみを待機できますしたがって Swiftの並行処理プリミティブを使用して構造化されたコードはタスク間の依存関係のチェーンをランタイムに明確に理解させますこれまで皆さんはSwiftの言語機能がどのようにタスクが待機中に停止させることができるかを学びました実行中のスレッドはタスクの依存関係について推論し別のタスクを選択することができますこれは Swift 並行処理で記述されたコードがスレッドが常に前進できる実行時の取決めを維持できることを意味しますこの実行時の取決めを利用して Swift 並行処理のための統合OSサポートを構築しますこれはSwift並行処理をデフォルトのエクセキュータとして支援するための新しい協調スレッドプール形式になっていますこの新しいスレッドプールでは CPU コアと同じ数のスレッドのみを生成するためシステムが過剰に動作しないことを保証をします作業項目がブロックされるとさらに多くのスレッドを生成する GCD の並行キューと異なり Swift スレッドは必ず実行を進めることができますデフォルトのランタイムが生成するスレッドの数を賢く制御しますこれにより過度の同時実行の既知の落とし穴を回避しながら Appに必要な並行処理を提供します Grand Central Dispatchによる並行処理についての前回の WWDCトークにおいて私たちは皆さんに Appを個別のサブシステムに構造化してサブシステムごとに1つのシリアルディスパッチキューを使って同時実行を制御することを推奨しましたこれだとスレッド爆増のリスクを冒さずにサブシステム内の並行処理を 1より大きくすることが困難であることを意味しました Swiftを使用するとこの言語はランタイムがを活用した強力な不変条件を提供するためデフォルトのランタイムでより適切に制御された並行処理を透過的に提供できます皆さんはSwift並行処理のスレッドモデルについてさらに多く理解したので皆さんのコードでこれらのわくわくする新規機能を採用する際に留意する事項についてお話ししましょう留意する必要がある一つ目の事項は同期コードを非同期コードに変換する際のパフォーマンスについてです先ほど私達は追加メモリーの配置及びSwift ランタイムなどの並行処理に関係するコストのお話をしましたコードに並行処理を導入するメリットがコードを管理するコストを上回っている場合にのみ Swiftの並行処理を使用した新しいコードを作成するよう注意する必要がありますこちらのコードはユーザーのデフォルトから値を読み取るためだけに子タスクを生成しており並行処理の追加の恩恵を受けられない可能性がありますこれは子タスクにより行われる役立つ作業がタスクを作成し管理するコストにより減少したためです Swiftの並行処理を採用する際のパフォーマンス特性を理解するために Instrumentsのシステムトレースを使用してプロファイリングすることをお勧めします気をつける二つ目のことは await に関するアトミック性の観念です Swift は await 前にコードを実行したスレッドが continuation を取得するスレッドと同じであることを保証しません実際 await はコード内の明示的なポイントでありタスクは自身でスケジュールを解除できるためアトミック性が壊れていることを示しますそのため待機中にロックを保持しないように注意する必要があります同様にスレッド固有のデータは awaitを挟んで保存されませんスレッドの局所性を期待するコード内の仮定は await の一時停止動作を考慮して再検討する必要がありますそして最後に考慮することは Swiftの効率的なスレッドモデルの基礎となるランタイムコントラクトに関係しています Swiftを使用するとこの言語によりスレッドが常に前進できるという実行時の取決めを維持できることを思い出してくださいこの取決めに基づいて Swiftのデフォルトのエグゼキュータとなる協調スレッドプールを構築しました Swiftの並行処理を採用するときは協調スレッドプールが最適に機能できるようにコードでもこの取決めを維持し続けることが重要ですコード内の依存関係を明示的かつ既知にする安全なプリミティブを使用することにより協調スレッドプール内でこの取決めを維持することができます await・アクター・タスクグループなどの Swift並行処理プリミティブを使用するとこれらの依存関係はコンパイル時に判明しますその為 Swift コンパイラはこれを強制し実行時の取決めを維持するよう促します os_unfair_locks や NSLocks などのプリミティブも安全ですがそれらを使用する時は注意が必要です同期コードでロックを使用することはタイトなクリティカルセクションでデータ同期に使用する場合に安全ですこれはロックを保持しているスレッドがロックの解除に向けて常に実行できるためですその時はプリミティブは競合下でスレッドを短期間ブロックする可能性がありますがフォワードプログレスの実行時の取決めに違反しません Swift並行処理プリミティブとは異なりロックの正しい使用方法を支援するコンパイラーのサポートはないためこのプリミティブを正しく使用するのはユーザーの責任です一方セマフォや条件変数などのプリミティブを Swift 並行処理で使用するのは安全ではありませんそれらはコードの実行に依存関係を作りますが Swift ランタイムから依存性情報は隠されてしまいますランタイムはこの依存関係を認識しないため正しいスケジューリング決定を行ってそれらを解決することができません特に構造化されていないタスクを生成するセマフォまたは安全でないプリミティブを使ってタスクの境界を越えた依存関係を遡及的に発生させないで下さいそのようなコードパターンは別のスレッドがセマフォのブロックを解除できるようになるまでスレッドがセマフォに対して無期限にブロックできることを意味しますこれはスレッドの順方向進行の実行時の取決めに違反しますあなたのコードでそのような安全でないプリミティブの利用を特定するため次の環境変数によりAppをテストしてくださいこれにより変更されたデバッグランタイムで Appが実行され順方向進行の不変条件が適用されますこの環境変数は次に示すように Xcode のプロジェクトスキームの Run > Arguments で設定できますこの環境変数を設定してAppを実行中に協調スレッドプールのスレッドがハングしているように見える場合は安全でないブロッキングプリミティブが使用されていることを示していますさてスレッドモデルがSwiftの並行処理向けにどのように設計されているかを学んだのでこの新しい世界で状態を同期するために利用できるプリミティブについてもう少し掘り下げてみましょうアクターに関するSwift並行処理の講演でアクターを使用して mutable を同時アクセスから保護する方法を見てきました言い換えるとアクターは強力な新しい同期プリミティブを提供しますアクターは相互排斥を保証することを思い出してくださいアクターは一度に最大1つのメソッド呼び出しを実行できます相互排斥とはアクターの状態に同時にアクセスしないことを意味しデータの競合を防ぎますアクターと他の形式の相互排斥を比較してみましょうシリアルキューに同期していくつかの記事でデータベースを更新する前の例を考えてみましょうキューがまだ実行されていない場合は競合はないと言いますこの場合呼び出し元のスレッドはコンテキストスイッチなしでキューの新規作業項目を実行するために再使用されます代わりにシリアルキューがすでに実行されている場合キューは競合しているということですこの状況では呼び出し元のスレッドはブロックされます最初の方でRokhiniが説明した通りこのブロック行為はスレッド爆憎を引き起こすものですロックにはこの同じ作用がありますブロックに関係する問題のため dispatch async を使用することをお勧めします dispatch async の主な利点はブロックしないことですそのためたとえ競合があってもスレッド爆増を起こしませんシリアルキューで dispatch async を使用する欠点は競合がない場合呼び出し元のスレッドが他のことを続けている間同時に非同期で作業を行なうには新規スレッドをリクエストする必要がありますこの故に dispatch async の頻繁な使用は過度のスレッド生成とコンテキストスイッチを引き起こす可能性がありますそこでアクターを使います Swiftのアクターは効率的なスケジューリングのために協調スレッドプールを利用することにより両方の世界の一番良い部分を組み合わせます実行中でないアクターでメソッドを呼び出すと呼び出し元のスレッドを再利用してメソッド呼び出しを実行します呼び出されたアクターがすでに実行中の場合呼び出し元のスレッドは実行中の関数を一時停止し他の作業を選択できますこれら二つのプロパティが例のニュースAppでどのように機能するかを見てみましょうデータベースとネットワークサブシステムに焦点を当てましょう Swift 並行処理を利用するためにAppを更新する際データベース用のシリアルキューはデータベースアクターに置き換えますネットワーク用の並行処理キューは各ニュースフィードごとに一つのアクターと置き換えます単純化のため三つのフィードアクターのみを表示しましたスポーツフィードお天気フィードそして健康フィードただし実際はさらに多くのものがありますこれらのアクターは協調スレッドプールで実行されますフィードアクターはデータベースにアクセスして記事を保存しその他のアクションを行いますこれにはあるアクターから他のアクターへの実行の切り替えが含まれますこの手順を「アクターホッピング」と呼びますアクターホッピングがどのように機能するかをお話ししましょうスポーツフィードのアクターが協調プールのスレッドで実行されておりいくつかの記事をデータベースに保存することを決定したとします現在データベースが使用されていないと考えますこれは競合のない場合ですスレッドはスポーツフィードファクターからデータベースアクターに直接ホップしますここで気づくことが二つありますまずアクターをホッピングしている間スレッドはブロックされませんでした第二にホッピングは別のスレッドを必要としませんでしたランタイムはスポーツフィードアクターのワークアイテムを直接一時停止させデータベースアクターの新しい作業項目を作成できますデータベースアクターがしばらく実行されますが最初の作業項目が完了していないとしますこの時天気フィードアクターがデータベースにいくつかの記事を保存しようとしていると仮定しますこれによりデータベースアクターの新しい作業項目が作成されますアクターは相互排斥を保証することによって安全性を確保します一度にアクティブにできる作業項目は最大で1つですアクティブな作業項目D1がすでに1つあるため新しい作業項目D2は保留されたままになりますアクターもノンブロッキングですこの状況では天気フィードアクターは一時停止され実行されていたスレッドは他の作業を行うために開放されます少し経過した後当初のデータベースリクエストが完了するとデータベースアクターのアクティブな作業項目は削除されますこの時点でランタイムはデータベースアクターの保留中の作業項目の実行を開始することを選択できますまたはフィードアクターの一つを再開することも選べますまたは解放されたスレッドでその他の作業を行うこともできます多くの非同期作業があるとき特に多くの競合があるとシステムはどの作業が最も重要かに基づいてトレードオフを行う必要があります理想的にはユーザーインタラクションを含むなど優先順位の高い作業がバックアップの保存などの裏方の作業に対して優先権を持ちますアクターはリエントラントの概念によりシステムが作業の優先順位をうまくつけられるように設計されていますここでリエントラントがなぜ重要なのかを理解するためまず GCD の優先権を処理する方法を見てみましょうシリアルデータベースキューを備えた先程のニュースAppについて考えてみますデータベースが UI を更新するための最新データを取ってくるなど高優先順位の作業を受け取るとしますまたデータベースをiCloudにバックアップするなど優先度の低い作業も受けますこれはある時点で行う必要がありますが必ずしもすぐに行う必要はありませんコードが実行されると新しい作業項目が作成されインターリーブされた順序でデータベースキューに追加されますディスパッチキューは受信した項目を厳格な先着順で実行しますあいにくこれは項目Aが実行された後次の高優先項目に達する前に 5つの低優先順位の項目が実行される必要がありますこれは「優先順位の逆転」と呼ばれますシリアルキューはキューの中の高い優先順位の作業の前にある全ての作業の優先順位を上げることにより優先順位の逆転を回避します実際にはこれはキュー内の作業がより早く行われることを意味しますただしアイテムBの実行を開始する前にアイテム1から5を完了する必要があるという主要問題を解決しませんこの問題の解決には厳格な先着順から離れてセマンティックモデルを変更する必要がありますアクターのリエントラントです再入可能性が順序決定にどのように繋がるかの例を挙げて見てみましょう
スレッドで実行しているデータベースアクターを考えましょうそれは停止していくつかの作業を待っておりスポーツフィードアクターがそのスレッドで実行を開始するとします少し経過した後スポーツフィードアクターが記事を保存するためデータベースアクターを呼び出しますデータベースアクターは競合していないため保留中の作業項目があってもスレッドはデータベースアクターにホップできます保存オペレーションを行うために新規作業項目がデータベースアクター用に作成されますこれがアクター再入可能性が意味することですアクターの新規作業項目は他の古い作業項目が停止されている間に実行される可能性がありますアクターは依然相互排斥を維持し特定の時間に実行できる作業項目は最大で1つですしばらくするとアイテムD2の実行が終了します D1の後に作成されたにもかかわらず D2がD1の前に実行を終了したことに注意してくださいしたがってアクターの再入可能性のサポートはアクターが厳密に先入れ先出しではない順序でアイテムを実行できることを意味します以前の例をもう一度見てみましょうただしシリアルキューの代わりにデータベースアクターを使用しますまず優先度が高い作業項目Aを実行しますそれが完了すると以前と同じ優先順位の逆転がありますアクターは再入可能性を考慮して設計されているためランタイムは優先度の低いアイテムよりも優先度の高いアイテムをキューの先頭に移動することを選択できますこのようにして優先度の高い作業を最初に実行し優先度の低い作業を後で実行することができますこれにより優先順位の逆転の問題に直接対処しより効果的なスケジューリングとリソースの利用が可能になります協調プールを使用するアクターが相互排斥を維持し作業の効果的な優先順位付けをサポートするように設計されていることについて少しお話ししました別の種類のアクターであるメインアクターの特性は既存のシステムの観念であるメインスレッドを抽象化するため幾分異なりますアクターを使用するニュースAppの事例を考えてみましょうユーザーインターフェースを更新するには MainActorに依頼する必要がありますメインスレッドは協調プールのスレッドから切り離されている為これにはコンテキストスイッチが必要ですコード例を使用してこのパフォーマンスの影響を見てみましょう次のコードを考えてください MainActor の updateArticles 関数があります記事をデータベースから読み込み各記事の UI を更新しますループの各反復には少なくとも2つのコンテキストスイッチが必要です一つはメインアクターからデータベースアクターへホップもう一つはポップして戻りますこのようなループの CPU 使用率を見てみましょう各ループの反復には 2つのコンテキストスイッチが必要なため 2つのスレッドが短時間次々に実行される繰り返しパターンがありますープの反復回数が少なく各反復でかなりの作業が行われている場合はおそらく問題ありませんしかしメインアクターを頻繁にオンオフする場合スレッド切り替えのオーバーヘッドが増加し始める可能性がありますコンテクストスイッチングに多くの時間を費やしている場合はメインアクターの作業がバッチ処理されるようにコードを再構築する必要がありますループを loadArticles および updateUI メソッドにまとめて一度に1つの値ではなく配列を処理するようにすることでバッチ作業を行うことができます作業をまとめることでコンテストスイッチの回数が減少します協調プール上のアクター間のホッピングは高速ですがメインアクターとの間のホップに注意する必要があります振り返ってみると協調スレッドプールの設計ノンブロッキングサスペンションのメカニズムアクターの実装方法までシステムを最も効率的にするためにどのように取り組んだかを学びました各ステップでランタイムコントラクトを使用して Appの性能を向上させていますこれらの信じられないほどの新しい言語機能を使用して明確で効率的で楽しいSwiftコードを作成する方法を見て興奮していますご視聴ありがとうございました WWDC をお楽しみください ♪

4:57 - GCD code with hidden performance pitfalls

func deserializeArticles(from data: Data) throws -> [Article] { /* ... */ }
func updateDatabase(with articles: [Article], for feed: Feed) { /* ... */ }

let urlSession = URLSession(configuration: .default, delegate: self, delegateQueue: concurrentQueue)

for feed in feedsToUpdate {
    let dataTask = urlSession.dataTask(with: feed.url) { data, response, error in
        // ...
        guard let data = data else { return }
        do {
            let articles = try deserializeArticles(from: data)
            databaseQueue.sync {
                updateDatabase(with: articles, for: feed)
            }
        } catch { /* ... */ }
    }
    dataTask.resume()
}

13:18 - Swift concurrency equivalent using a task group

func deserializeArticles(from data: Data) throws -> [Article] { /* ... */ }
func updateDatabase(with articles: [Article], for feed: Feed) async { /* ... */ }

await withThrowingTaskGroup(of: [Article].self) { group in
    for feed in feedsToUpdate {
        group.async {
            let (data, response) = try await URLSession.shared.data(from: feed.url)
            // ...
            let articles = try deserializeArticles(from: data)
            await updateDatabase(with: articles, for: feed)
            return articles
        }
    }
}

15:16 - Async functions: stack frames and async frames

// on Database
func save(_ newArticles: [Article], for feed: Feed) async throws -> [ID] { /* ... */ }

// on Feed
func add(_ newArticles: [Article]) async throws {
    let ids = try await database.save(newArticles, for: self)
    for (id, article) in zip(ids, newArticles) {
        articles[id] = article
    }
}

func updateDatabase(with articles: [Article], for feed: Feed) async throws {
    // skip old articles ...
    try await feed.add(articles)
}

37:13 - Excessive context switching due to Main actor hoppping

// on database actor
func loadArticle(with id: ID) async throws -> Article { /* ... */ }

@MainActor func updateUI(for article: Article) async { /* ... */ }

@MainActor func updateArticles(for ids: [ID]) async throws {
    for id in ids {
        let article = try await database.loadArticle(with: id)
        await updateUI(for: article)
    }
}

38:18 - Batch UI work to reduce the number of context switches

// on database actor
func loadArticles(with ids: [ID]) async throws -> [Article]

@MainActor func updateUI(for articles: [Article]) async

@MainActor func updateArticles(for ids: [ID]) async throws {
    let articles = try await database.loadArticles(with: ids)
    await updateUI(for: articles)
}

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

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC23

WWDC22

WWDC21

WWDC17

WWDC16