Reactive Framework、PLINQ、TPL 和并行扩展如何相互关联？

Question

至少自.NET 4.0发布以来，微软似乎在支持并行和异步编程方面投入了大量精力，并且似乎出现了很多围绕此的API和库。尤其是最近到处不断提到下面这些花哨的名字：

• Reactive Framework、
• PLINQ（Parallel LINQ）、
• TPL（Task Parallel Library）和
• Parallel Extensions。

现在它们似乎都是 Microsoft 产品，并且它们似乎都针对 .NET 的异步或并行编程场景。但目前尚不清楚它们各自的实际含义以及它们之间的关系。有些实际上可能是同一件事。

简而言之，谁能澄清什么是什么？

Answer 1

PLINQ（并行 Linq）只是一种编写常规 Linq 查询的新方法，以便它们并行运行 - 换句话说，框架将自动负责跨多个线程运行查询，以便它们完成更快（即使用多个 CPU 核心）。

例如，假设您有一堆字符串，并且想要获取所有以字母“A”开头的字符串。您可以这样编写查询：

var words = new[] { "Apple", "Banana", "Coconut", "Anvil" };
var myWords = words.Select(s => s.StartsWith("A"));

这工作得很好。但是，如果您有 50,000 个单词要搜索，您可能希望利用每个测试都是独立的这一事实，并将其拆分到多个核心上：

var myWords = words.AsParallel().Select(s => s.StartsWith("A"));

这就是将常规查询转变为运行在多个核心。相当整洁。

---

TPL（任务并行库）是 PLINQ 的补充，它们共同构成了并行扩展。尽管 PLINQ 主要基于函数式编程风格，无副作用，但副作用正是 TPL 的用途。如果您想实际上并行工作，而不是仅仅并行搜索/选择内容，则可以使用 TPL。

TPL 本质上是 Parallel 类，它公开了 For、Foreach 和 Invoke 的重载。 Invoke 有点像在 ThreadPool 中排队任务，但使用起来更简单。 IMO，更有趣的部分是 For 和 Foreach。举例来说，假设您有一大堆要压缩的文件。您可以编写常规的顺序版本：

string[] fileNames = (...);
foreach (string fileName in fileNames)
{
    byte[] data = File.ReadAllBytes(fileName);
    byte[] compressedData = Compress(data);
    string outputFileName = Path.ChangeExtension(fileName, ".zip");
    File.WriteAllBytes(outputFileName, compressedData);
}

同样，此压缩的每次迭代都完全独立于任何其他迭代。我们可以通过同时执行其中几个来加快速度：

Parallel.ForEach(fileNames, fileName =>
{
    byte[] data = File.ReadAllBytes(fileName);
    byte[] compressedData = Compress(data);
    string outputFileName = Path.ChangeExtension(fileName, ".zip");
    File.WriteAllBytes(outputFileName, compressedData);
});

同样，这就是并行化此操作所需的全部内容。现在，当我们运行 CompressFiles 方法（或者我们决定调用它的任何名称）时，它将使用多个 CPU 核心，并且可能会在一半或 1/4 的时间内完成。

与将其全部放入线程池相比，这样做的优点是它实际上是同步运行的。如果您使用 ThreadPool 来代替（或者只是简单的 Thread 实例），您必须想出一种方法来找出所有任务何时完成，并且虽然这并不是非常复杂，但很多人往往会搞砸或者至少遇到麻烦。当您使用Parallel类时，您实际上不必考虑它；多线程方面对您来说是隐藏的，它全部在幕后处理。

---

反应式扩展 (Rx) 确实是一种完全不同的野兽。这是考虑事件处理的不同方式。关于这一点确实有很多内容需要介绍，但长话短说，Rx 可以让您将事件序列视为...以及序列 (IEnumerable)，而不是将事件处理程序连接到事件。 ）。您可以以迭代方式处理事件，而不是让它们在随机时间异步触发，您必须始终保存状态才能检测以特定顺序发生的一系列事件。

我发现的 Rx 最酷的例子之一是 这里。跳到“Linq to IObservable”部分，他仅用 4 行代码就实现了一个拖放处理程序，这在 WPF 中通常是一个难题。 Rx 为您提供了事件的组合，这是常规事件处理程序所不具备的，并且像这样的代码片段也可以直接重构为可以嵌入到任何地方的行为类。

---

就是这样。这些是 .NET 4.0 中提供的一些更酷的功能。当然还有更多，但这些是您询问的！

Answer 2

我喜欢 Aaronaught 的回答，但我想说 Rx 和 TPL 解决不同的问题。 TPL 团队添加的部分内容是线程原语以及对 ThreadPool 等运行时构建块的重大增强。您列出的所有内容都构建在这些原语和运行时功能之上。

但 TPL 和 Rx 解决两个不同的问题。当程序或算法“拉动和拉动”时，TPL 效果最佳。排队'。当程序或算法需要对流中的数据做出“反应”时（例如鼠标输入或从 WCF 等端点接收相关消息流时），Rx 表现出色。

您需要 TPL 中的“工作单元”概念来完成文件系统等工作、迭代集合或遍历组织结构图等层次结构。在每种情况下，程序员都可以推断出工作总量，可以将工作分解为一定大小的块（任务），并且在通过层次结构进行计算的情况下，可以将任务“链接”在一起。因此，某些类型的工作适合 TPL“任务层次结构”模型，并受益于取消等管道的增强功能（请参阅 CancellationTokenSource 上的第 9 频道视频）。 TPL 还拥有许多针对专业领域的旋钮，例如近实时数据处理。

Rx 将是大多数开发人员最终应该使用的。这就是 WPF 应用程序如何对外部消息（如外部数据（发送至 IM 客户端的 IM 消息流）或外部输入（如 Aaronaught 链接的鼠标拖动示例））进行“反应”。在幕后，Rx 使用来自 TPL/BCL 的线程原语、来自 TPL/BCL 的线程安全集合以及 ThreadPool 等运行时对象。在我看来，Rx 是表达意图的“最高级别”编程。

普通开发人员是否能够理解可以用 Rx 表达的一系列意图还有待观察。 :)

但我认为未来几年 TPL 与 Rx 将成为下一场争论，就像 LINQ-to-SQL 与实体框架一样。同一领域中有两种 API，专门针对不同的场景，但在很多方面都有重叠。但在 TPL 和 TPL 的情况下Rx 它们实际上彼此了解，并且有内置适配器来组合应用程序并一起使用这两个框架（例如将 PLINQ 循环的结果馈送到 IObservable Rx 流中）。对于那些没有做过任何并行编程的人来说，需要大量的学习才能加快速度。

更新：过去 6 个月（自我最初回答以来的 18 个月），我一直在日常工作中使用 TPL 和 RxNet。我在中间层 WCF 服务（企业 LOB 服务）中选择 TPL 和/或 RxNet 的想法： http://yzorgsoft.blogspot.com/2011/09/middle-tier-tpl-andor-rxnet.html