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

This entry was posted in Best Practices. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s