Zlatko Michailov 再谈任务并行库数据流（TPL Data Flow）

我们对《自定义任务并行库数据流块实现指南》（Guide to Implementing Custom TPL Dataflow Blocks）的作者——Zlatko Michailov 进行了一个简短的采访。

InfoQ：在你看来，TPL 数据流（TPL Dataflow）最适合于哪些应用程序？而对哪些应用程序又不太适合？

TPL 数据流是一个流处理平台，它可以处理音频 / 视频帧流、价格报价波动流等。当消息以高频率到来时，TPL 数据流特别适用。使用它之后，你会看到高效率平台和非高效平台之间的差距。

通常使用数据流平台的一个额外好处是：数据流网络拓扑会参与到处理过程中。应用程序会由一个个小而精的代理（delegate）构成，从而使应用程序更易维护。

InfoQ：你认为 TPL 数据流今后会是一个少数人使用的高级技术？还是你认为它会很大程度取代 Task，就像 Task 取代线程一样？

我认为都不会。TPL 数据流不会取代 Task。（我也不认为 Task 取代了线程；Task 只是填补了并发编程里的一块空白。）TPL 数据流借用 Task 实现了众多模式。虽然其主模式是流处理，但是每一个数据流块（block）都很常规，且可以用于其他用途。例如，WriteOnce 块被设计用作请求 - 响应机制——WriteOnce 块实例化基于请求之上，一旦响应数据写回它就会自动完成，从而让请求方可以继续异步地进行工作。另外一个例子是结合 MaxDegreeOfParallelism 选项的 ActionBlock——它可以用作限流（throttling mechanism），防止同时被处理的任务数目超过指定数量。第三个例子是结合 BoundedCapacity 选项的 BufferBlock，它用作对数据来源进行限流。所以在我看来，TPL 数据流在普遍情况下都是适用的。

InfoQ：你觉得对于刚刚使用 TPL 数据流的新手而言，需要学习的最重要的东西是什么？

纯属个人意见——最重要的是需要意识到线程很昂贵，并且不应当压迫操作系统创建不必要的线程。开发人员应当关注任务间的从属关系，并依靠操作系统和框架完成那些任务的安排。

对于 TPL 数据流，我建议开发人员对每个块进行单独测试。没准你会发现某个块（block）实现的模式是你经常使用的那个。如果看到某个模式和你用过的很接近但是又不是非常像，可以考虑将多个内置块进行封装来组成该模式。如果那样做还不奏效，你也许可以编写一个简单的同步块来填补这个空缺。

InfoQ：你建不建议将 TPL 数据流和 Windows 工作流（Windows Workflow）混在一起使用？

Windows 工作流的目标是让花上数天或者甚至数月才能持久性流能够完成。它关注的是可靠性而不是性能。相反，TPL 数据流纯粹以性能为目的。它的目标就是使用最有效可行的方法来利用所有可用的硬件资源。所以技术上来说，你是可以混用这两个技术的。我的猜想是你可以将 TPL 数据流放入 Window 工作流中的某个步骤中来使用。

查看英文原文： http://www.infoq.com/news/2012/01/Zlatko-TPL