Zlatko Michailov 再谈任务并行库数据流(TPL Data Flow)

  • Jonathan Allen
  • 曹如进

2012 年 2 月 27 日

话题:.NET语言 & 开发架构

我们对《自定义任务并行库数据流块实现指南》(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

.NET语言 & 开发架构