非同期処理の基礎

非同期処理の基礎知識岩永信之

今日話すこと • 非同期処理がらみの良い書き方/悪い書き方 • それがなぜ良い/悪い • 突き詰めるとCPUやOSレベルの話に

非同期処理の書き方良い例・悪い例を紹介先に事例紹介(良い・悪い理由は後ほど)

ThreadよりもTask for (int i = 0; i < num; i++) { var t = new Thread(_ => b[i] = F(a[i]) ); } for (int i = 0; i < num; i++) { Task.Run(() => b[i] = F(a[i]) ); } ×悪い例 ○良い(まだマシ※な)例データの数だけスレッド作成 Threadでなく Task利用 ※ この場合、ParallelクラスやParallel.Enumerableクラスが使いやすい

ThreadよりもTask for (int i = 0; i < num; i++) { var t = new Thread(_ => b[i] = F(a[i]) ); } for (int i = 0; i < num; i++) { Task.Run(() => b[i] = F(a[i]) ); } ×悪い例 ○良い(まだマシ※な)例データの数だけスレッド作成 Threadでなく Task利用 ※ この場合、ParallelクラスやParallel.Enumerableクラスが使いやすい題材 • スレッドのコスト • スレッドプール

非同期I/O using (var r = new StreamReader("some.txt")) { var t = r.ReadToEndAsync(); Console.WriteLine(await t); } using (var r = new StreamReader("some.txt")) { var t = Task.Run(() => r.ReadToEnd()); Console.WriteLine(await t); } Task.Run ＋同期I/O 非同期I/O用メソッド ×悪い例 ○良い例

非同期I/O using (var r = new StreamReader("some.txt")) { var t = r.ReadToEndAsync(); Console.WriteLine(await t); } using (var r = new StreamReader("some.txt")) { var t = Task.Run(() => r.ReadToEnd()); Console.WriteLine(await t); } Task.Run ＋同期I/O 非同期I/O用メソッド ×悪い例 ○良い例題材 • CPU-boundとI/O-bound • I/O完了ポート

データ競合 var count = 0; Parallel.For(0, num, i => { ++count; }); var count = 0; Parallel.For(0, num, i => { lock (sync) ++count; }); 期待通りに動かない count == numにならない lockをかけるととりあえず期待通りにはなる ×悪い例 ○良い(まだマシ※な)例 ※ Interlocked.Incrementメソッド使えばlockなしでスレッド安全にインクリメントできる性能を考えると、次節のスレッドローカルを使う方がいい

データ競合 var count = 0; Parallel.For(0, num, i => { ++count; }); var count = 0; Parallel.For(0, num, i => { lock (sync) ++count; }); 期待通りに動かない count == numにならない lockをかけるととりあえず期待通りにはなる ×悪い例 ○良い(まだマシ※な)例 ※ Interlocked.Incrementメソッド使えばlockなしでスレッド安全にインクリメントできる性能を考えると、次節のスレッドローカルを使う方がいい題材 • 競合が起きる理由 • lock

スレッドローカル var count = 0; Parallel.For(0, num, () => 0, (i, state, localCount) => localCount + 1, localCount => count += localCount ); var count = 0; Parallel.For(0, num, i => { lock (sync) ++count; }); ×悪い例 ○良い例 (さっきの「マシな例」) lockしてスレッド間で同じデータを読み書きスレッドごとに別計算最後に集計

スレッドローカル var count = 0; Parallel.For(0, num, () => 0, (i, state, localCount) => localCount + 1, localCount => count += localCount ); var count = 0; Parallel.For(0, num, i => { lock (sync) ++count; }); ×悪い例 ○良い例 (さっきの「マシな例」) lockしてスレッド間で同じデータを読み書きスレッドごとに別計算最後に集計題材 • スレッド並列 • 並列化しやすいアルゴリズム

イベントの実装(前置き) event EventHandler Disposed; 自動実装イベント event EventHandler Disposed { add { _disposed += value; } remove { _disposed -= value; } } private EventHandler _disposed; こんな意味合いのコードに対して、「スレッド安全」が求められる (C#の規格上そう定めてある) C#のイベント「自動実装」の結果 (意味的には)

イベントの実装 [MethodImpl(MethodImplOptions.Synchronized)] add { _disposed += value; } lock (this)相当 add { EventHandler handler2; var disposed = _disposed; do { handler2 = disposed; var handler3 = (EventHandler)Delegate.Combine(handler2, va disposed = Interlocked.CompareExchange(ref _disposed, hand } while (disposed != handler2); } ×C# 3.0までの実装(悪い例) ○C# 4.0以降の実装(良い例) lock-free※アルゴリズム ※ lockを使わずに競合を避けること

イベントの実装 [MethodImpl(MethodImplOptions.Synchronized)] add { _disposed += value; } lock (this)相当 add { EventHandler handler2; var disposed = _disposed; do { handler2 = disposed; var handler3 = (EventHandler)Delegate.Combine(handler2, va disposed = Interlocked.CompareExchange(ref _disposed, hand } while (disposed != handler2); } ×C# 3.0までの実装(悪い例) ○C# 4.0以降の実装(良い例) 題材 • interlocked命令 • lock-freeアルゴリズム lock-free※アルゴリズム ※ lockを使わずに競合を避けること

基礎今の事例はいったん置いておいて CPUとかOSレベルの話を

CPU まず、CPUの動作について

CPU = 演算回路+記憶領域 ALU メイン・メモリデータを格納高速・小容量加減乗除などの演算を実行† データを格納低速・大容量 † arithmetic logic unit 演算回路記憶領域

CPU = 演算回路+記憶領域 ALU メイン・メモリ記憶領域には階層がある高速小容量 ⇔ 低速大容量演算回路と直接つながってるのは、 1番高速で、1番小容量の記憶

CPUの動作例 • 高級言語的に1ステートメントでも… ALU メイン・メモリ ++count; ① mov eax, [04D74010h] ② inc eax ③ mov [04D74010h], eax C# CPU命令コンパイル

CPUの動作例 ① 読み込み ALU メイン・メモリ ① mov eax, [04D74010h] ② inc eax ③ mov [04D74010h], eax ++count; C# CPU命令コンパイル

CPUの動作例 ② 演算 ALU メイン・メモリ ① mov eax, [04D74010h] ② inc eax ③ mov [04D74010h], eax +1 ++count; C# CPU命令コンパイル

CPUの動作例 ③ 書き出し ALU メイン・メモリ ① mov eax, [04D74010h] ② inc eax ③ mov [04D74010h], eax ++count; C# CPU命令コンパイル

CPUの動作例 ③ 書き出し ALU メイン・メモリ ① mov eax, [04D74010h] ② inc eax ③ mov [04D74010h], eax ++count; C# CPU命令コンパイルポイント • 単純な処理でも複数命令からなる • 読み込み、演算、書き出し • 上から順に逐次実行

注意: 読み込みの原子性※ ALU メイン・メモリ 64bit データ ALU メイン・メモリデータ64bit ※ atomicity: 不可分性。中途半端な不正な状態を起こさないこと 64bit CPUの場合 32bit CPUの場合 1命令完結 2命令必要命令と命令の間に割り込まれるとデータが半分しか読まれてない状態になる

割り込み CPUと、CPUの外の世界(ハードウェア割り込み) 特権モード(ソフトウェア割り込み)

CPUの外の世界 • 当然、CPUだけでは何もできない ALU メイン・メモリ CPU 周辺機器割り込み信号

割り込み • 外部ハードウェアから「割り込み信号」が来る • 信号を受け取ると、実行中の処理を止めて、いったん別処理をする命令列別の処理外部ハードウェアからの信号を受け取って、処理を中断再開 mov eax, [04D74010h] inc eax mov [04D74010h], eax ……

割り込みタイミング • 割り込みはどこでかかるかわからない mov eax, [04D74010h] inc eax mov [04D74010h], eax …… ここで割り込まれるかもしれないしここもここもここもありえる

ハードウェアタイマー • 一定間隔で割り込み信号を送ってくるハードウェアがある • スレッドで使う(詳細は後述) 命令列ハードウェアタイマー割り込み割り込み割り込み … 別の処理別の処理別の処理

ソフトウェア割り込み • 割り込み命令命令列別の処理自分自身で割り込みを起こせる命令がある再開割り込み発生命令 ……

モード切り替え • 何に使うかというと、モード切り替え命令列別の処理割り込み発生命令 …… 通常のセキュリティレベルで動作特権的なセキュリティレベルで動作異なるモードで動作

特権モードユーザーモード • 一般のプログラムに認められるセキュリティレベル • アクセスできるメモリに制限がある特権モード※ • OSが使うセキュリティレベル • 制限がかからないモード移行にはそれなりのコストが発生 ※ OSのカーネルが使うんで、カーネルモード(kernel mode)ともいう

CPUの高度化キャッシュメモリマルチコアCPU

• 記憶領域の階層は多段メインメモリ 2次キャッシュメモリキャッシュ ALU キャッシュメモリ高速小容量低速大容量速度差が大きすぎるキャッシュ1段ごとに1桁くらい遅い

• 記憶領域の階層は多段メインメモリ 2次キャッシュメモリキャッシュ ALU キャッシュメモリ高速小容量低速大容量このサイズに収まる範囲で読み書きする分には高速広範囲にデータを読み書きすると、低速なメモリへの読み書きが発生

• コアごとにキャッシュ持ってたりメインメモリ 2次キャッシュメモリマルチコア ALU キャッシュメモリ ALU キャッシュメモリ ALU キャッシュメモリ

• コアで同じデータを読み書きするとメインメモリ 2次キャッシュメモリマルチコア ALU キャッシュメモリ ALU キャッシュメモリ ALU キャッシュメモリ同じブロックを読み書きしているつもりでも実際には別の場所にある 1段下(低速)に書き戻されてないと正しい値が取れない = 1桁遅い

• 非均一な読み書き速度 NUMA※ ALU キャッシュメモリ ALU キャッシュメモリ ALU キャッシュメモリ ※ non-uniform memory access: 非均一なメモリアクセスメモリノード1 メモリノード2 メモリノード3 高速アクセスはできるものの、低速

• 非均一な読み書き速度 NUMA※ ALU キャッシュメモリ ALU キャッシュメモリ ALU キャッシュメモリ ※ non-uniform memory access: 非均一なメモリアクセスメモリノード1 メモリノード2 メモリノード3 高速アクセスはできるものの、低速ポイント • コアをまたいだデータ読み書きはかなり低速

スレッドマルチタスク CPUのシェア

マルチタスク • コンピューター内で複数のタスクが同時に動作 • CPUコア数に制限されないタスク1 タスク2 タスク3 … タスクの動作期間実際にCPUを使って動いている期間 1つのCPUコアを複数のタスクがシェアしてる問題は • どうやって他のタスクにCPUを譲るか • 誰がどうスケジューリングするか

2種類のマルチタスク † preemptive: 専買権を持つ、横取りする ※cooperative • ハードウェアタイマーを使って強制割り込み • OSが特権的にスレッド切り替えを行う • ○利点: 公平 (どんなタスクも等しくOSに制御奪われる) • ×欠点: 高負荷 (切り替えコストと使用リソース量が多い) プリエンプティブ† • 各タスクが責任を持って終了する • 1つのタスクが終わるまで次のタスクは始まらない • ○利点: 低負荷 • ×欠点: 不公平 (1タスクの裏切りが、全体をフリーズさせる) 協調的※ なのでスレッドはこっちこれが致命的ただ、問題はこれ

スレッドを立てるコスト※ • スレッドに紐づいたデータ • カーネルステート: 1kBくらい • ローカルスタック: 1MBくらい • イベント発生 • Thread Attached/Detachedイベント ※ Windowsの場合

スレッド切り替えコスト • 直接的なコスト • 特権モードへの移行・復帰 • レジスターの保存・復元 • 次に実行するスレッドの決定 • スレッドの状態を入れ替え • 間接的なコスト • キャッシュミスどれも性能へのインパクト大きい

スレッドは高コスト • 細々としたタスクを大量にこなすには向かない for (int i = 0; i < 1000; i++) { var t = new Thread(Worker); t.Start(); } 大量の処理をスレッド実行リソース消費大切り替え頻発 …

スレッドプール • スレッドを可能な限り使いまわす仕組み • プリエンプティブなスレッド数本の上に • 協調的なタスクキューを用意スレッドプールキュータスク1 タスク2 … 数本※のスレッドだけ用意空いているスレッドを探して実行（長時間空かない時だけ新規スレッド作成）新規タスクタスクは一度キューに溜める ※ 理想的にはCPUのコア数分だけ

スレッドプールの性能向上 • Work Stealing Queue • lock-free実装(後述)なローカルキュー • できる限りスレッド切り替えが起きない作りローカルキュー1 ローカルキュー2 スレッド1 スレッド2 グローバルキュー ① スレッドごとにキューを持つまず自分用のキューからタスク実行 ② ローカルキューが空のとき、他のスレッドからタスクを奪取

スレッドプールの性能向上 • Work Stealing Queue • lock-free実装(後述)なローカルキュー • できる限りスレッド切り替えが起きない作りローカルキュー1 ローカルキュー2 スレッド1 スレッド2 グローバルキュー ① スレッドごとにキューを持つまず自分用のキューからタスク実行 ② ローカルキューが空のとき、他のスレッドからタスクを奪取ポイント • スレッドは高コスト • Threadくらすはこっち • スレッドプールの利用推奨 • Taskクラスはこっち

I/O完了ポート外部ハードウェアからの応答を待つ

CPUの外の世界は遅い • 実行速度が全然違う ALU メイン・メモリ CPU 周辺機器数千～下手すると数万、数億倍遅い

2種類の負荷 • CPU-bound (CPUが性能を縛る) • マルチコアCPUの性能を最大限引き出したい • UIスレッドを止めたくない • I/O-bound (I/O※が性能を縛る) • ハードウェア割り込み待つだけ • CPUは使わない • スレッドも必要ない ※ Input/Output: 外部ハードウェアとのやり取り(入出力)

I/O完了待ち • I/O-boundな処理にスレッドは不要あるスレッド要求応答この間何もしないのにスレッドを確保し続けるのはもったいない

I/O完了ポート※ • スレッドを確保せずI/Oを待つ仕組み • コールバックを登録して、割り込みを待つ • コールバック処理はスレッドプールでスレッドプールタスク1 タスク2 … ※ I/O completion port あるスレッドアプリ I/O完了ポートハードウェア I/O開始 I/O完了コールバック登録コールバック登録後、すぐにスレッド上での処理を終了割り込み信号

I/O完了ポート※ • スレッドを確保せずI/Oを待つ仕組み • コールバックを登録して、割り込みを待つ • コールバック処理はスレッドプールでスレッドプールタスク1 タスク2 … ※ I/O completion port あるスレッドアプリ I/O完了ポートハードウェア I/O開始 I/O完了コールバック登録コールバック登録後、すぐにスレッド上での処理を終了割り込み信号ポイント • I/O-boundな処理にスレッドを使っちゃダメ • I/O用の非同期メソッドが用意されてる (内部的にI/O完了ポートを利用)

事例に戻って良い例・悪い例の理由

ThreadよりもTask for (int i = 0; i < num; i++) { var t = new Thread(_ => b[i] = F(a[i]) ); } for (int i = 0; i < num; i++) { Task.Run(() => b[i] = F(a[i]) ); } ×悪い例 ○良い(まだマシ※な)例データの数だけスレッド作成 Threadでなく Task利用 ※ この場合、ParallelクラスやParallel.Enumerableクラスが使いやすい

おさらい • Threadクラス • Windowsの生スレッド • = プリエンプティブなマルチタスク • 当然重たい • 特権モード移行、レジスター退避、… • Taskクラス • スレッドプールを利用 • 必要な分だけスレッド使う推奨スレッドは生で使うものじゃない

非同期I/O using (var r = new StreamReader("some.txt")) { var t = r.ReadToEndAsync(); Console.WriteLine(await t); } using (var r = new StreamReader("some.txt")) { var t = Task.Run(() => r.ReadToEnd()); Console.WriteLine(await t); } Task.Run ＋同期I/O 非同期I/O用メソッド ×悪い例 ○良い例

おさらい • I/O-boundな処理のためにスレッドを専有しちゃダメ • I/O完了ポート使う • ハードウェアからの割り込みをイベント処理 • 標準ライブラリの～Async系のメソッドはこれを利用非推奨 Task.Run(() => r.ReadToEnd()); 推奨 r.ReadToEndAsync();

おまけ: SleepよりもDelay Task.Delay((int)(x * Scale)) .ContinueWith((_, state) => { sorted.Enqueue((double)state); }, x); var t = new Thread(state => { var value = (double)state; Thread.Sleep((int)(value * Scale)); sorted.Enqueue(value); }); t.Start(x); スレッドを立ててから Thread.Sleepで休止 Task.Delayで休止 ×悪い例 ○良い例 • 何もしないのにスレッドを確保し続ける • タイマー利用 (ハードウェア割り込み) • スレッドを確保しない

データ競合 var count = 0; Parallel.For(0, num, i => { ++count; }); var count = 0; Parallel.For(0, num, i => { lock (sync) ++count; }); 期待通りに動かない count == numにならない lockをかけるととりあえず期待通りにはなる ×悪い例 ○良い(まだマシ※な)例 ※ Interlocked.Incrementメソッド使えばlockなしでスレッド安全にインクリメントできる性能を考えると、次節のスレッドローカルを使う方がいい

おさらい • スレッドはハードウェアタイマーの割り込みを使ってる • 割り込みはいつかかるかタイミング不定 • 単純なコードでも、CPUレベルでは複数命令 ++count; C# CPU命令コンパイル ① 読み mov eax, [04D74010h] ② 計算 inc eax ③ 書き mov [04D74010h], eax

競合 • 複数のスレッドで同じ場所を読み書きすると… シングルスレッドマルチスレッド読み計算書き読み計算書き読み計算読み計算読み計算書き読み計算書き …… …… switch switch 書き込み終わる前にスレッドが切り替わることがある • 計算前の値を再度読んじゃうだいぶ昔の計算結果で上書き • 別スレッドで計算してた分が消える

lock • 競合回避のためにlock (鍵)をかける switch switch lock獲得 lock解放 lock獲得獲得失敗他のスレッドがlock獲得しようとすると失敗するその場でいったんスレッド実行を停止読み計算書き

lock • 競合回避のためにlock (鍵)をかける switch lock獲得 lock解放獲得～解放の間は、同時に2つ以上のスレッドで実行されなくなる読み計算書き lock獲得 lock解放読み計算書き

lockの仕組み • OSのスレッドスケジューラーに依頼 • lockがかかっていると、スケジューラーがスレッド実行を止める • 特権モードが必要 • 無駄にスレッド切り替えが増える高コスト switch switch lock獲得 lock解放 lock獲得獲得失敗読み計算書きスレッド切り替えも高コスト

スレッドローカル var count = 0; Parallel.For(0, num, () => 0, (i, state, localCount) => localCount + 1, localCount => count += localCount ); var count = 0; Parallel.For(0, num, i => { lock (sync) ++count; }); ×悪い例 ○良い例 (さっきの「マシな例」) lockしてスレッド間で同じデータを読み書きスレッドごとに別計算最後に集計

おさらい • lockは高コスト • 特権モードが必要 • 無駄なスレッド切り替え発生 • スレッド間のデータ共有は高コスト • (特に書き込み) • キャッシュからメインメモリへの書き戻し • コアごとのキャッシュへの伝搬 • NUMA (非均一メモリアクセス)

スレッドごとの独立性 • 性能を求めるなら • スレッド間での同じ場所の読み書きをなくす • Parallelクラスにはそのためのオーバーロードあり var count = 0; Parallel.For(0, num, () => 0, (i, state, localCount) => localCount + 1, localCount => count += localCount ); スレッドごとに別々に+1 最後にスレッドごとの結果を足す

気を付けるポイント • 独立に計算できないと、並列化の利益少ない • 順序依存とかがあると無理交換法則、結合法則が大事これが成り立たない演算は並列化に向かないさっきの++countループの例だとこの辺りに気を使ってアルゴリズム考える必要あり和を2つに分解 (分解しても計算結果が一緒)

イベントの実装 [MethodImpl(MethodImplOptions.Synchronized)] add { _disposed += value; } lock (this)相当 add { EventHandler handler2; var disposed = _disposed; do { handler2 = disposed; var handler3 = (EventHandler)Delegate.Combine(handler2, va disposed = Interlocked.CompareExchange(ref _disposed, hand } while (disposed != handler2); } lock-free※アルゴリズム ×C# 3.0までの実装(悪い例) ○C# 4.0以降の実装(良い例) ※ OS機能(特権モード必要)のlockを使わずに競合を避けること

おさらい • lockは高コスト(再) • 特権モードが必要 • 無駄なスレッド切り替え発生 • 旧実装はlock [MethodImpl(MethodImplOptions.Synchronized)] add { _disposed += value; } add { lock(this) { _disposed += value; } } ※ lock(this)は性能面以外にも問題あり旧コードはいろんな意味でレガシー ※

新実装 • lockなしで競合回避するためのアルゴリズム add { EventHandler handler2; var disposed = _disposed; do { handler2 = disposed; var handler3 = (EventHandler)Delegate.Combine(handler2, valu disposed = Interlocked.CompareExchange(ref _disposed, handle } while (disposed != handler2); } こいつがポイント

Interlocked • CPUには「必ず原子的※に実行する保証付き」な命令がいくつかある(interlocked命令) • .NETの場合、Interlockedクラスを利用 ※ atomic: 不可分な。途中で他のスレッドなどに割り込まれない保証 var count = 0; Parallel.For(0, num, i => { Interlocked.Increment(ref count); }); 例: 原子性保証付きのインクリメント挙動的にはlock付きの++countと同じ

lockとinterlocked命令 • lockはOS機能 • 特権モード移行が必要 • スレッド切り替えの機会を増やす • 任意の処理をlockできる • Interlocked命令は単なるCPU命令 • 特権モード不要 • lockよりはだいぶ低コスト • とはいえ、普通の命令と比べると1桁くらいは遅い • 単純な処理しか用意されてない • インクリメントとか

CAS※ • 特に重要なのがCAS命令 • .NET的にはInterlocked.CompareExchangeメソッド ※ compare and swapの略。比較しながら交換 Intel CPUの命令名称的には compare exchange int CompareExchange(ref int loc, int value, int comp) { int ret = loc; if (ret == comp) loc = value; return ret; } ↓こういう意味のコードを原子性保証付きで実行する命令比較しながらの値の交換

CAS • 何が重要かというと • 競合が起きたことを検知できる • 「競合を避ける」よりははるかに低コスト int CompareExchange(ref int loc, int value, int comp) { int ret = loc; if (ret == comp) loc = value; return ret; } 競合してたら元のlocとは違う値が返る

新実装がやってること • 競合が見つかったらやりなおし add { EventHandler handler2; var disposed = _disposed; do { handler2 = disposed; var handler3 = (EventHandler)Delegate.Combine(handler2, valu disposed = Interlocked.CompareExchange(ref _disposed, handle } while (disposed != handler2); } 競合検知しながらの交換競合してたら最初からやりなおしいわゆる「楽観的排他制御」 eventの+=が競合することはほとんどないので、ほぼ1発

注意 • この手のlock-freeアルゴリズムは書くの大変 • 書いたはいいけど、テストが大変 • 普通はライブラリまかせ • Taskクラス(が使ってるスレッドプール) • System.Collections.Concurrent名前空間内のクラス • eventの自動実装(C# 4.0以降) 内部的にlock-free実装なものの例:

まとめ • スレッドは高コスト • スレッドプール(Taskクラス)推奨 • I/O-boundな処理にスレッド不要 • ～Asyncメソッドの利用推奨 • 競合 • lockが必要 • できればlockも避ける • そもそもスレッド間でデータ共有しないアルゴリズム • lock-freeアルゴリズム(interlocked命令) • 競合を避けるよりは、検知してやり直しの方が低コスト

非同期処理の基礎

by 信之岩永, Working at Microsoft MVP on May 11, 2014

Statistics

Views

Actions

1 Embed 34

Accessibility

Categories

Upload Details

Usage Rights

Report content