この何年かの間に、マルチスレッド プログラムが段々ホットな話題になってきている。高い応答性のユーザインタフェースが何十年も必要とされてきたが、その必要性を満たすツールは、そんなに変わっていない。ユーザインタフェースの更新は、なお.NETで入手できるものを含んで、ほとんどのフレームワークでは、単一スレッドで行われている。一方、ハードウェア メーカーは、CPUのスピードを早くする代わりに、複数コアに向かっている。
C#とVBは、非同期ライブラリを使った、モニターやデリゲートのための lock/SyncLockキーワードを介した、非常に単純化した並列性のサポートから始めた。その後の数バージョンでは、この領域では意味のある進歩はなかった。注目されたのは他の領域だった。.NET 4.0では、事情は全く変わった。3つの新しいライブラリが導入された。Task Parallel Library (TPL), Parallel LINQ, そして Coordination Data Structures (CDS)である。これらのライブラリは、ラムダ、クロージャそしてLINQのようなシンタックスの強化改善をベースに作られており、非常に簡単にマルチスレッド開発ができるようになる。しかし、ライブラリを使うという事実を取り去ることはできなかった。 Parallel LINQは、非常にうまく動いているようであるが、TPLの非同期呼び出しは、なお見るからにやっかいで、いささか間違いを起こしやすい。
今日の非同期パターンの大きな問題は、それらがうまく組上がっていないことである。各非同期操作は、コールバックを使って次の操作と繋がっている。しかしコールバックは、組み立てることができない。それぞれコールバックは、独立した関数で、ループ、 usingや try-catchブロックのような共通のコード構造にまとめることができない。
その結果、ほとんどの開発者は、実際には非同期パターンを使っていない。並列なマルチスレッド化を行わずに、バックグラウンド スレッドやマニュアルの同期化に頼っている。しかし、これはこれで問題がある。ブロッキングI/Oでスレッドを待たせることにより、 I/Oコンプリーション ポート のようなオペレーティングシステムが提供するパフォーマンスやスケーラビリティの恩恵を受けずにいる。多くのスレッドに伴うメモリーのオーバーヘッドも言うに及ばずである。その代わりに、単一スレッドとループを使っているので、各I/O操作は、前のが終了するまで開始できない。
とは言うものの、我々は長い間このようにコードを書いてきたし、殆どの環境でうまくいっている。一般にコンピュータは、十二分なスピードとメモリーを持っており、下手なスレッドの使い方でも問題ないし、UIスレッドにデータをマーシャリングして戻すのも負荷にならない。では、何が変わったのか？
3つ変わった。
まず基礎プロジェクト。Async CTP は、単独で発明されたわけではない。その多くを研究とそれ以前の幾つもの製品プロジェクトをベースにしている。その中には、非同期言語の Axum、Task Parallel Library (TPL)、 Reactive Extensions (Rx)そしてF#の非同期ワークフローがある。これらの開発はすべて終わり、VB/C# 内の非同期シンタックスが次の理にかなったステップである。
2番目が関わった人達である。多くの研究プロジェクトのように新卒者を行き当たりで使うのではなく、Somasegar 氏は、5人の非常に有能なPMによるチームを作って、非同期プログラムを同期プログラムのように簡単に書けるシンタックスを作る仕事をさせた。これら5人は、Avner Aharoni 、Mads Torgersen, Stephen Toub, Alex Turner, そして Lucian Wischikの各氏で、皆.NETの開発でよく知られている人達である。彼らのスキルと献身がなければ、このCTPは、できなかっただろう。
最後がSilverlightである。Flashにとって代わるかは別として、Silverlightは、Microsoftのモバイル戦略に不可欠である。ゲームを作っているのでなければ、Silverlightを使わずに Windows Phone 7用のアプリケーションを書くことはできない。そしてSilverlightは、同期I/Oをサポートしない。WPFのコードをSilverlightにポートしようとした人は、誰でも知っているが、そのようなものはないのである。非同期パターンを使う以外にないのである。Lucian 氏が彼の “Async CTPの技術的紹介”の中でこのことがいかに複雑かを示している。
もちろん、このことは、必然的にC# と VB が非同期シンタックスをサポートするように変わることを意味している。もしこのことが C# 5/VB 11で実際に盛り込まれたなら、セマンティックが間違っているので、これを取り去ろうとしてもほとんどあるいは、全くできないだろう。そしてこれにともなって、他のフィーチャまでもが「サービスとしてのコンパイラー」から無数の小さな、低品質問題までを抱えることになる。