最近は、タスクベースの非同期パターン（TAP）というもので、非同期処理を実装していきます。
でも過去は違いました。
考え方が違うというところ。これにやられました。
そんなところで、振り返ってみました。
.Net Framework 1.1 非同期呼び出しの組み込み
デリゲートを使って、非同期に実行することができた。
.Net Framework 2.0 イベント ベースの非同期パターンを使用したマルチスレッド プログラミング
非同期処理をデリゲートで実現するとどうしても、処理の流れが見えにくかった。
それを問題を解決してくれたのが、これだと思ってます。
このときから、.Netのスレッドモデルが変わって、ネイティブのスレッドを見ちゃいけないぞーってなった。変わりにマネージスレッドというものを扱うように。これは、非同期の処理でスレッドプールなるものが、自動的にうまいことやるから、気にしなくていいっていうものだった。
.Net Framework 2.0 BackgroundWorker クラス
デザイナから、上記イベントベースの非同期パターンを実装するコンポーネントとして貼り付けられた。もちろん4.5でも残ってる。
「ながい処理」の後に「終わったよーっていう通知をUIで表現する」ケースだとぴったり。
でも、小刻みな処理や、複数のバックグラウンドの処理を同時に実行させると最終的な同期の問題とか。要するに上記のようなケース以外だと何かしら、手を加える必要があった。
.Net Framework 4.0 の並列プログラミング
まさに、小刻みな処理を非同期化するために生まれてきた感じがした。
パソコンもマルチコアが当たり前だった。
ここからは、非同期で実装するというよりも、並列に処理するっていうところが違う。
タスクという一つのメソッド・・・クロージャ、プロシージャ・・・デリゲートのインスタンスをうまいことやってくれる。
.Net Framework 4.5 非同期プログラミングのパターン
そして、改めて今までの実装方法が整理された様子。
非同期プログラミング モデル (APM)
イベント ベースの非同期パターン (EAP)
タスク ベースの非同期パターン (TAP)
Async および Await を使用した非同期プログラミング
言語レベルで非同期になりました。
Asyncなイベントハンドラを作って、MSILに逆アセンブルしてみると中身が面白いです。
コードは、一本なのに実体は非同期です。
まとめ
過去のことをその時代ほど知る必要はなくとも
それぞれのモデル・パターンを知っておかないと、
いつの間にかぐちゃぐちゃになってしまったりするので、その助けになれば幸いです。
// EAPで実装されたものに、TAPで追加実装したりすると
// 大変なことになって結局書き直すか、あきらめるかの選択を迫られることになったり・・・ｗ