連載:C# 5.0&VB 11.0新機能「async/await非同期メソッド」入門 第1回 .NET開発における非同期処理の基礎と歴史 鈴木 孝明2012/08/31 |
|
Page1
Page2
|
■.NET Frameworkにおける非同期処理実装技術の歴史
それでは、.NET Frameworkがこれまでに提供してきた非同期処理実装技術の進化の歩みについて、復習も兼ねながら見ていこう。大まかにいうとFigure 3のようになる。
Figure 3: .NET Frameworkにおける非同期処理システムの歩み |
これらの各技術を対比することで、最新技術である非同期メソッドの簡単さがより理解できるのではないかと思う。
今回は非同期処理のサンプルとして、ボタンをクリックした際に、下記の一連の処理を行うものとする。
- ボタンをDisableにする
- 何か時間のかかる処理する
- ボタンをEnableにする
いうまでもないことだが、最も基本となるUIスレッドに同期的な記述をするとList 1のようになる。
|
||
List 1: UIに同期的に処理を行う例(上:C#、下:VB) |
たったこれだけだが、これを非同期処理にすると、どういう実装になるのかを技術別に順番に見ていこう。きっと初めて非同期メソッドをご覧になる方はその簡単さに驚くことだろう。
●Thread(スレッド)
まず、.NET Framework 1.1時代からある最も原始的なThreadクラス(System.Threading名前空間)を用いた方法を紹介しよう。
Threadクラスは、Figure 2で出てきた「別スレッド」そのものを表したもので、1つのインスタンスを生成すると、スレッドが1つ生成される。作成したスレッド上で行う処理をインスタンス生成時にデリゲートとして渡しておき、Startメソッドにより処理を開始する。List 2にその実装例を示す。
|
||
List 2: Threadクラスによる非同期処理の実装例(上:C#、下:VB) |
ここではラムダ式という形でThreadクラスのコンストラクタにデリゲートを登録しているが、.NET Framework 1.1時代は、ラムダ式はおろか、匿名メソッドすら存在しなかった。この場合、メソッドを用意し、そのデリゲートを直接セットすることになるのだが、その方法だと戻り値を受けることが困難だった。
今では匿名メソッドやラムダ式があり、クロージャ*1によってローカル変数の受け渡しが簡単にできるので、このような問題はあまり露呈しなくなったが、当時はとても大変だった。
*1 変数を、自身が定義された静的なスコープで解決することができる機能。「進化したC# 2.0の状態管理、匿名メソッドとイテレータ」で詳しく解説されている。 |
また先の例では、ボタンを有効な状態に戻す際に、Dispatcher(=WPF/SilverlightにおけるウィンドウのDispatcherプロパティで取得できるオブジェクト)のBeginInvokeメソッドを利用している。これは、.NET Frameworkに「ボタンなどのUIコンポーネントの操作は、UIスレッド上でしか行えない」という制約があるためだ。WPFやSilverlightの場合はDispatcher.BeginInvokeメソッドを、Windowsフォームの場合はControl.Invokeメソッドを利用することで、UIスレッドに処理を戻すことができる。
また、これらを抽象化し、開発環境を問わずに統一的な記述ができるSynchronizationContextクラス(System.Threading名前空間)を利用してもよい。いずれにせよ、明示的にUIに処理を戻さなければならない煩雑さがある。
そして何よりも問題なのは、開発者がスレッドというものを直接意識し、生成・管理・破棄しなければならないことだ。このような極めてシステム寄りな事象について思案しなければならないのは、コーディングにおいて大いなる雑念でしかない。可能ならば隠ぺいし、書きたい処理だけに集中したいものだ。
●ThreadPool(スレッドプール)
実は、スレッドの生成/破棄には思いのほか、コストがかかる。例えば、スレッドを1つ生成すると、約1Mbytesのメモリを消費するし(=空間的なコスト)、スレッドの生成/破棄のたびにプロセス内にロードされている全ての.dllファイルのDllMain関数が呼び出される(=時間的なコスト)。このようなオーバーヘッドを極小にするために考えられたのが「スレッドプール(ThreadPool)」だ。
スレッドプールは、生成・使用したスレッドを破棄せずに使い回すリサイクル・センターのようなもので、TPL(Task Parallel Library: 並列処理ライブラリ)やI/O待ちなど、.NET Frameworkのいたるところで利用されるスレッド管理の根幹をなす重要な機能だ。このスレッドプールを表すThreadPoolクラス(System.Threading名前空間)を利用した実装例をList 3に示す。
|
||
List 3: ThreadPoolクラスによる非同期処理の実装例(上:C#、下:VB) |
ThreadPool.QueueUserWorkItemメソッドを利用している点を除けば、Threadクラスとほとんど変わらないことが分かるだろう。パフォーマンスの観点から、明示的にスレッドを作らなければならないケースを除いて、このスレッドプールを利用する方が望ましい。
●Asynchronous Programming Model(非同期プログラミング・モデル)
.NET Frameworkで初めて提供された、スレッドを直接意識しない非同期処理システムが「APM(Asynchronous Programming Model)」だ。BeginXxxとEndXxxのメソッドのペアで実装を行う。前述のThreadやThreadPoolと大きく異なるのは、非同期処理の結果を戻り値の形で受けることができる点だ。List 4に実装例を示す。
|
||
List 4: APMによる非同期処理の実装例(上:C#、下:VB) |
すでにお気付きかもしれないが、記述の仕方が非常に煩雑だ。.NET Framework標準で提供されているメソッドを利用するだけならまだしも、BeginXxx/EndXxxメソッドの独自実装をサラッとはなかなか書けない。今では、その複雑さからこの手法はあまり利用されない傾向にある。
●Event-based Asynchronous Pattern(イベントベースの非同期パターン)
WindowsフォームやWebフォームが全盛期の時代に登場した、完了や進捗(しんちょく)の通知などをイベントによるコールバックの形で提供する非同期処理システムが「EAP(Event-based Asynchronous Pattern)」だ。List 5にその実装例を示す。
|
||
List 5: EAPによる非同期処理の実装例(上:C#、下:VB) |
メソッド単位で処理を意味的に分離できるため、比較的見通しよく記述できる。また、これまでに紹介した非同期処理システムでは、UIコンポーネントの操作のためにUIスレッドに戻す記述を明示的に行っていたが、EAPではUIスレッド上に戻したうえで完了処理をコールバックしてくれる*2。半面、非同期処理の開始より先に非同期処理の本体や完了処理を登録しなければならず、コードの順序が処理フローと逆転するというデメリットもある。
*2 .NET Frameworkが提供するEAPに限ってであり、独自実装時は開発者自身がUIスレッドに戻す挙動を担保しなければならない。 |
●Task-based Asynchronous Pattern(タスクベースの非同期パターン)
.NET Framework 4で搭載された並列処理ライブラリ「TPL」の要であり、本連載の主題である非同期メソッドを支える根幹機能でもあるTaskクラス(System.Threading.Tasks名前空間)を利用した手法が「TAP(Task-based Asynchronous Pattern)」だ。
Taskクラスは「何か非同期的に実行する操作」を表したものと考えればよい。そこから結果を受け取ったり、完了を待機したり、完了後に続けて別の処理を行ったりできるなど、非常に高い柔軟性を持っている。List 6にそのTaskクラスを使った非同期処理の実装例を示す。
|
||
List 6: TAPによる非同期処理の実装例(上:C#、下:VB) |
Task.Factory.StartNewメソッドは、Taskの生成と実行を一挙に行うものだ。ここで指定したデリゲートを非同期に実行するという点は最初に紹介したThreadとそっくりだが、都度、スレッドを1つ生成しているわけではない。内部ではThreadPoolが利用されており、空いているスレッドに自動的に作業が割り振られる。そのため、実行コストは最小限に抑えられている。
ContinueWithメソッドに渡したデリゲートは、元のタスクが完了した後に実行される。また、第2引数にはTaskScheduler.FromCurrentSynchronizationContextメソッドで取得したUIスレッドに同期的なスケジューラを設定している。そのため、ContinueWithメソッドはUIスレッド上で動作することになり、ボタンの有効化を実行することができる。
このようにTAPでは、「○○を非同期に実行してください。○○が完了したら△△の処理を実行してください。ただし、△△はUIスレッド上で動作させてください」のように処理のフローや意図を分かりやすく表現できる。
●Reactive Extensions(Rx)
Rx(Reactive Extensions)は通常のLINQをイベント処理や非同期処理に拡張したもので、.NET Framework 3.5から利用することができる準標準ライブラリ*3である。これを利用すると、List 7の例(C#のみ。VBは割愛)のようにイベントの関連付けからスレッド間の移動までを全てメソッド・チェーンの形で記述できる。
*3 .NET Framework本体には搭載されていないが、マイクロソフトが正規のプロダクトとして提供している追加のライブラリ。 |
|
|
List 7: Rxによる非同期処理の実装例(C#) |
ここまで見てきた非同期処理とはだいぶ毛色が違うが、宣言的な記述になっているため処理フローが非常に分かりやすいのが特徴だ。また、例外処理やリトライなどにも柔軟に対応することもでき、非同期メソッドに並んで最も有用な機能の1つとなっている。
Rxは非常に奥が深いライブラリなので、興味のある方は「連載:Reactive Extensions(Rx)入門」や「xin9le note - Rx入門」などを参考にしてほしい。
●async/await
そして最後が、.NET Framework 4.5に対応したC# 5.0やVB 11.0で搭載された「非同期メソッド」(=async修飾子とawait演算子を利用したメソッド)だ。さっそく、そのコードを見てみよう。
|
||
List 8: async/awaitによる非同期処理の実装例(上:C#、下:VB) |
いかがだろうか。ほぼ最初に紹介した同期処理の記述と同じであることが分かるだろう。相違点は以下の3点だけだ。
- メソッドにasyncキーワードが付加されている
- 実処理をTaskで記述している
- Taskの前にawaitキーワードが付加されている
同期処理にたったこれだけの変更を加えるだけで非同期化される。これまではボタンの再有効化のために明示的にUIスレッドに処理を戻す記述をしていたが、もはやそれすらも必要ない。また、コードがあちこちに分散することもないので処理のフローが明快になる。同期処理と同じ流れで非同期処理を書く、それが非同期メソッドの最大の魅力だ。
■まとめ
ここまで順を追って歴代の非同期処理システムについて見てきた。この流れで非同期メソッドを見ると、非同期処理を行ううえでの無駄がきれいに省かれていることが分かる。APMやEAPの記述と比べると、まるで魔法のようにさえ感じることだろう。しかし、非同期メソッドは記述が楽になるだけで、非同期処理自体が持つ本来の難しさ*4がなくなるわけではない。その点は誤解がないようにしなければならないし、十分注意してほしい。
*4 排他制御やデッドロックなど。 |
さて次回は、非同期メソッドの書き方や利用上の注意点などをより詳細に解説する予定だ。ぜひ、楽しみに待っていてほしい。それでは、また次回。
INDEX | ||
連載:C# 5.0&VB 11.0新機能「async/await非同期メソッド」入門 | ||
第1回 .NET開発における非同期処理の基礎と歴史 | ||
1.非同期処理の必要性/非同期処理の基本のキ | ||
2..NET Frameworkにおける非同期処理実装技術の歴史 | ||
「連載:C# 5.0&VB 11.0新機能「async/await非同期メソッド」入門」 |
- 第2回 簡潔なコーディングのために (2017/7/26)
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために (2017/7/19)
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator (2017/7/18)
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
|
|
- - PR -