この記事はカスタムTPL Dataflowブロック実装ガイドの著者、Zlatko Michailov氏へのインタビューを要約したものである。
InfoQ: どのようなアプリケーションが特にTPL Dataflowに適しているとお考えですか？また、どんな場合は適していないのでしょうか？
TPL Dataflowはストリーム処理のプラットフォームです。ストリームには、例えばオーディオフレームやビデオフレームのストリームや、株価のストリームなどがあります。メッセージが頻繁にやってくるようなアプリケーションにとって特に効果的です。
一般的に、データフロープラットフォームを利用すると、データフローネットワークのトポロジが処理に関与するという利点もあります。従って、アプリケーションは小さく、特定の部分に焦点を絞ったデリゲートで構成されることになり、メンテナンスが容易になります。
InfoQ: TPL Dataflowは利用シーンが限定的な、高度なテクニックだとお考えですか？それとも、TPL Dataflowは広く利用され、Taskがスレッドに取って代わったようにTaskを置き換えるようなものなのでしょうか？
どちらでもないと思います。TPL DataflowはTaskを置き換えるものではありません(ちなみに、私はTaskがスレッドに置き換わったのではなく、Taskは並列プログラミングのギャップを埋める存在だと考えています)。TPL DataflowはTaskを使ったパターンを実装しています。主なパターンはストリーミング処理ですが、それぞれのブロックは汎用的なので他の目的で利用することも可能です。例えば、WriteOnceブロックはリクエスト-レスポンス用に設計されています – WriteOnceブロックのインスタンスはリクエストに対して生成され、リクエスト送信元が非同期に処理を続けられるように、一度レスポンスデータが書き込まれると自動的に完了します。２つ目の例は、MaxDegreeOfParallelismオプションと組み合わせActionBlockです – それは処理を制限する(同時に実行する処理タスクの数が指定された数以上にならないようにする)仕組みとして利用できます。３つ目の例は、データフィードを調整するBoundedCapacityオプションと組み合わせたBufferBlockです。このようなものがあるので、私はTPL Dataflowは一般的に適用可能だと思っています。
InfoQ: 初めてTPL Dataflowに取り掛かるにあたり、学習すべき最も重要なことは何でしょうか？
これは私見ですが、スレッドは高価(expensive)でありOSに不必要なスレッドを作成させるべきではない、ということを理解するのが最も重要だと思います。開発者はタスク間の依存関係に集中し、タスクのスケジューリングはOSやフレームワークに任せるべきです。
開発者には特に、それぞれのブロックを個別に試してほしいと思っています。頻繁に利用するパターンを実装したブロックを見つけることができるでしょう。もし使いたいものに近いが全く同じではないパターンに出会ったら、あなたが必要とするパターンを実現するために複数のビルドインブロックでカプセル化することを検討してみてください。必要なブロックがなければ、シンプルな同期ブロックを作成して不足分を補うこともできます。
InfoQ: TPL DataflowとWindows Workflowを一緒に利用するのを推奨していらっしゃいますか？
Windows Workflow(WF)の目標は、通常は完了に数日から数カ月かかるフローを持続させることです。WFの関心は信頼性であり、パフォーマンスではありません。一方、TPL Dataflowのターゲットは完全にパフォーマンスであり、その目標は可能な限り最も効果的な方法でCPUを活用することです。ですから、技術的にはTPL DataflowとWFを一緒に使うことは可能です。私はWFステップの中でTPL Dataflowを使うのがよいと思います。