いまさら恥ずかしくてAsyncをawaitした
9 likes•6,710 views
いまさら恥ずかしくてasyncをawaitした 第9回まどべんよっかいち in じばさん三重 開発室 http://www.kekyo.net/2014/07/26/%e3%81%84%e3%81%be%e3%81%95%e3%82%89%e6%81%a5%e3%81%9a%e3%81%8b%e3%81%97%e3%81%8f%e3%81%a6async%e3%82%92await%e3%81%97%e3%81%9f-%e7%ac%ac9%e5%9b%9e%e3%81%be%e3%81%a9%e3%81%b9%e3%82%93%e3%82%88/
いまさら恥ずかしくてAsyncをawaitした
- 1. いまさら恥ずかしくて asyncをawaitした 第9回まどべんよっかいちin じばさん三重開発室Kouji Matsui (@kekyo2)
- 3. Agenda 非同期処理の必要性とは？ Hello world的な非同期 スレッドとの関係は？ 非同期対応メソッドとは？ LINQでの非同期 競合条件の回避 非同期処理のデバッグ もりすぎにゃー
- 4. 時代は非同期！！ ストアアプリ（WinRT）環境では、外部リソースへのアクセスは非同期しかない。 ASP.NETでも、もはや使用は当たり前。 大規模実装事例も出てきた。 グラニさん「神獄のヴァルハラゲート」http://gihyo.jp/dev/serial/01/grani/0001 C# 2.0レベルの技術者は、これを逃すと、 悲劇的に追従不能になる可能性があるワ。 そろそろCやJava技術者の転用も不可能ネ。 → 実績がないよねー、とか、 いつの話だ的な
- 5. 何で非同期？ 過去にも技術者は非同期処理にトライし続けてきた。 基本的にステート管理が必要になるので、プログラムが複雑化する。 （ex : 超巨大switch-caseによる、ステート遷移の実装） それを解消するために、「マルチスレッド」が考案された。 マルチスレッドは、コンテキストスイッチ（CPUが沢山あるように見せかける、OSの複 雑な機構）にコストが掛かりすぎる。 → 揉まれてけなされてすったもんだした挙句、 遂に「async-await」なる言語機能が生み出された
- 6. Hello 非同期！ クラウディア窓辺公式サイトから、素材のZIPファイルをダウンロードしつつ、 リストボックスにイメージを表示します。 ワタシが表示されるアプリね 中には素材画像が入ってるワ。 もちろん、ダウンロードとZIPの展開は オンザフライ、GUIはスムーズなのヨネ？
- 7. 問題点の整理 ウェブサイトからダウンロードする時に、時間がかかる可能性がある。 GUIが操作不能にならないようにするには、ワーカースレッドを使う必要がある。 → ヤダ（某技術者談） ZIPファイルを展開し、個々のJPEGファイルをビットマップデータとして展開するのに、 時間がかかる可能性がある。 GUIが操作不能にならないようにするには、ワーカースレッドを使う必要がある。 → ヤダ（某技術者談） ＿人人人人人人＿ ＞ヤダ＜ ￣^Y^Y^Y^Y^Y^Y￣ 斧投げていいすか？（怒
- 8. Hello 非同期！（非同期処理開始） イベントハンドラが実行されると、 awaitの手前までを実行し… すぐに退出してしまう！！ （読み取りを待たない） スレッド１ スレッド１ スレッド１＝メインスレッド スレッド退出時にusing句の Disposeは呼び出されません。 あくまでまだ処理は継続中。
- 9. Hello 非同期！（非同期処理実行中） 非同期処理 スレッド１ 他ごとをやってる。 ＝GUIはブロックされない カーネル・ハードウェアが 勝手に実行
- 10. Hello 非同期！（非同期処理完了） await以降を継続実行 スレッド１ スレッド１ 非同期処理 処理の完了がスレッド１に 通知され… 完了 スレッド１が処理を継続実行 していることに注意！！
- 11. 少しawaitをバラしてみる C# 4.0での非同期処理は、ContinueWithを使用して継続処理を書いていました。 スレッド１ スレッド１ このラムダ式は、 コールバックとして実行される 非同期処理 スレッド２
- 13. await以降の処理を行うスレッド awaitで待機後の処理は、メインスレッド（スレッド１）が実行する。 そのため、Dispatcherを使って同期しなくても、GUIを直接操作できる。 メインスレッドへの処理の移譲は、Taskクラス内で、SynchronizationContextクラスを 暗黙に使用することで実現している。 →とりあえず、メインスレッド上でawaitした場合は、 非同期処理完了後の処理も、自動的にメインスレッドで 実行されることを覚えておけばOK （WPF/WP/ストアアプリの場合）。
- 14. 非同期対応メソッドとは？ メソッド名に「～Async」と 付けるのは慣例 Taskクラスを返す async-awaitを使っているか どうかは関係ない
- 15. ところで、応答性が悪い… 待つこと数十秒。 しかも、その間GUIがロック… いきなり全件表示 何コレ… （怒
- 16. 非同期にしたはずなんです… 非同期処理にしたのは、HttpClientがウェブサーバーに要求を投げて、HTTP接続が確立 された所までです。 非同期処理 ここの処理は同期実行、 しかもメインスレッドで！ ＝ここが遅いとGUIがロックする
- 17. 列挙されたイメージデータをバインディング メソッド全体が普通の同期メソッドなので、 ExtractImagesが内部でブロックされれば、 当然メインスレッドは動けない。 スレッド１ ExtractImagesメソッドが返す 「イテレーター（列挙子）」を列挙しながら、 バインディングしているコレクションに追加。 ObservableCollection<T>なので、 Addする度にListBoxに通知されて 表示が更新される。
- 18. 肝心な部分の実装も非同期対応にしなきゃ！ ストリームをZIPファイルとして解析しつつ、 JPEGファイルであればデコードして イメージデータを返す 「イテレーター（列挙子）」 ZipReader(ShartCompress) を使うことで、 解析しながら、逐次処理を行う事が出来る。 ＝全てのファイルを解凍する必要がない しかし、ZipReaderもJpegBitmapDecoderも、 非同期処理には対応していない。 スレッド１
- 20. ワーカースレッド≠ System.Threading.Thread ワーカースレッドと言っても、System.Threading.Threadは使いません。 System.Threading.ThreadPool.QueueUserWorkItemも使いません。 これらを使って実現することも出来ますが、もっと良い方法があります。 それが、TaskクラスのRunメソッドです
- 21. Task.Run() 処理をおこなうデリゲートを指定 Taskクラスを返却 結局はThreadPoolだが…
- 22. ワーカースレッドをTask化する イテレーターを列挙していた処理を Task.Runでワーカースレッドへ ワーカースレッドで実行するので、 Dispatcherで同期させる必要がある。 スレッド１ Task.Runはすぐに処理を返す。 その際、Taskクラスを返却する。 スレッド１ スレッド２
- 23. 呼び出し元から見ると、まるで非同期メソッド Taskクラスを返却するので、 そのままawait可能。 スレッド１ スレッド１ ワーカースレッド処理完了後は、 awaitの次の処理（Dispose）が実行される。
- 24. ワーカースレッドABC TaskCompletionSource<T>クラスを使えば、受動的に処理の完了を通知できるTaskを作れるので、 これを使って従来のThreadクラスを使うことも出来ます。 （ここでは省略。詳しくはGitHubのサンプルコードを参照） ワーカースレッドを使わないんじゃなかったっけ？ →「非同期対応メソッドが用意されていることが前提」です。 そもそも従来のようなスレッドブロック型APIでは、このような動作は実現出来ません。 ということは、当然、スレッドブロック型APIには、対応する非同期対応バージョンも欲しいよね。 →WinRTでやっちゃいました、徹底的に（スレッドブロック型APIは駆逐された）。 非同期処理で応答性の高いコードを書こうとすると、 結局ブロックされる可能性のAPIは全く使えない事になる。 だから、これからのコードには 非同期処理の理解が必須になるのヨ
- 25. 非同期処理vs ワーカースレッド 全部Task.Runで書けば良いのでは？ →Task.Runを使うと、ワーカースレッドを使ってしまう。 ThreadPoolは高効率な実装だけど、それでもCPUが処理を実行するので、従来の手法と変わら なくなってしまう。 （ネイティブな）非同期処理は、ハードウェアと密接に連携し、CPUのコストを可能な限り使わず に、並列実行を可能にする（CPU Work OffLoads）。 →結果として、よりCPUのパワーを発揮する事が出来ます。 （Blogで連載しました。参考にどうぞhttp://kekyo.wordpress.com/category/net/async/） Task.Runを使用する契機としては、二つ考えられます。区別しておくこと。 CPU依存型処理（計算ばっかり長時間）。概念的に、非同期処理ではありません。 →まま、仕方がないパターン。だって計算は避けられないのだから。 レガシーAPI（スレッドブロック型API）の非同期エミュレーション。 →CPU占有コストがもったいないので、出来れば避けたい。
- 26. LINQでも非同期にしたいよね… LINQの「イテレーター」と相性が悪い。 → メソッドが「Task<IEnumerable<T>>」を返却しても、列挙実行の実態が 「IEnumerator<T>.MoveNext()」にあり、このメソッドは非同期バージョンがない。 EntityFrameworkにこんなインターフェイスががが。 しかし、MoveNextAsyncを誰も理解しないので、 応用性は皆無…
- 27. 隙間を埋めるRx 単体の同期処理の結果は、「T型」 複数の同期処理の結果は、「IEnumerable<T>型」 単体の非同期処理の結果は、「Task<T>型」非同期処理 LINQ (Pull) ただの手続き型処理 T T T T T 複数の結果が不定期的（非同期） にやってくる(Push) Observer<T> データが来たら処理 （コールバック処理） Observable<T> 複数の非同期処理の結果は、「IObservable<T>型」 Reactive Extensions (Push)
- 28. イメージ処理をRxで実行 LINQをRxに変換。 列挙子の引き込みを スレッドプールのスレッドで実施 以降の処理をDispatcher経由 （つまりメインスレッド）で実行 要素毎にコレクションに追加。 完全に終了する（列挙子の列挙する要素 がなくなる）とTaskが完了する 列挙子（LINQ）
- 29. Rxのリレー IEnumerable<T> 0 1 2 3 4 ToObservable() 0 1 2 3 4 ワーカースレッドが要素を 取得しながら、細切れに送出 Pull Push ObserveOn Dispatcher() メインスレッドが要素を 受け取り、次の処理へ ForEachAsync() Task これら一連の処理を表すTask。 完了は列挙が終わったとき WPF ListBox Observable Collection Binding
- 30. Rxについてもろもろ LINQ列挙子のまま、非同期処理に持ち込む方法は、今のところ存在しません。 IObservable<T>に変換することで、時間軸基準のクエリを書けるようになるが、慣れが必要です。 →個人的にはforeachとLINQ演算子がawaitに対応してくれれば、もう少し状況は良くなる気がする。 http://channel9.msdn.com/Shows/Going+Deep/Rx-Update-Async-support-IAsyncEnumerable- and-more-with-Jeff-and-Wes Rxは、Observableの合成や演算に真価があるので、例で見せたような単純な逐次処理には、あまり旨みが ありません。それでもコード量はかなり減ります。 xin9leさん: Rx入門 http://xin9le.net/rx-intro 初めてx^2=-1 を導入した時の ようなインパクトがあります、 いろいろな意味で。
- 31. 非同期処理にも競合条件がある 同時に動くのだから、当然競合条件があります。 ボタンを連続でクリックする 画像がいっぱい入り乱れて 表示される こ、これはこれで良いかも？www
- 32. 競合条件の回避あるある この場合は、単純に処理開始時にボタンを無効化、処理完了時に再度有効化すれば良いでしょう。 従来的なマルチスレッドの競合回避知識しかない場合の、「あるある」 error CS1996: 'await' 演算子は、lock ステートメント本体では使用できません。
- 33. モニターロックはTaskに紐づかない モニターロックはスレッドに紐づき、Taskには紐づきません。無理やり実行すると、容易に デッドロックしてしまう。 同様に、スレッドに紐づく同期オブジェクト（ManualResetEvent, AutoResetEvent, Mutex, Semaphoreなど）も、Taskに紐づかないので、同じ問題を抱えています。 Monitor.EnterやWaitHAndle.WaitAny/WaitAllメソッドが非同期対応（awaitable）では ないことが問題（スレッドをハードブロックしてしまう）。 えええ、じゃあどうやって競合 を回避するの？！
- 34. とってもすごいライブラリ！ Nito.AsyncEx（NuGetで導入可） モニター系・カーネルオブジェクト系の同期処理を模倣し、非同期対応にしたライブラリです。 だから、とても馴染みやすい、分かりやすい！ await可能なlockとして使える AsyncSemaphoreを使えば、 同時進行するタスク数を制御可能
- 35. 非同期処理のデバッグ 「並列スタックウインドウ」 いろいろなスレッドとの関係がわかりやすい 「タスクウインドウ」 タスクはスレッドに紐づかない →スタックトレースを参照してもムダ
- 36. まとめ ブロックされる可能性のある処理は、すべからくTaskクラスを返却可能でなければなりません。 でないと、Task.Runを使ってエミュレーションする必要があり、貴重なCPUリソースを使う ことになります。そのため、続々と非同期対応メソッドが追加されています。 CPU依存性の処理は、元々非同期処理に分類されるものではありません。これらの処理は、 ワーカースレッドで実行してもかまいません。その場合に、Task.Runを使えば、Taskに紐づ かせることが簡単に出来るため、非同期処理と連携させるのが容易になります。 連続する要素を非同期で処理するためには、LINQをそのままでは現実的に無理です。Rxを使 用すれば、書けないこともない。いかに早く習得するかがカギかな… 非同期処理にも競合条件は存在します。そこでは、従来の手法が 通用しません。外部ライブラリの助けを借りるか、そもそも 競合が発生しないような仕様とします。 フフフ
- 37. ありがとうございました まにあったかにゃー 本日のコードはGitHubに上げてあります。 https://github.com/kekyo/AsyncAwaitDemonstration このスライドもブログに掲載予定です。 http://kekyo.wordpress.com/