c# - TPL 数据流和异步方法调用

Question

我试图更好地理解并行处理的整个概念，并设置了测试用例。进行测试后，我发现在 Dataflow ActionBlock(或 TransformBlock)中使用异步方法调用不会对性能产生积极影响，它只会使代码复杂化。我是否正确地假设如果我使用数据流 block ，其中的代码不必是异步的，数据流将使它自己异步。还是我没捕获要点？

Answer 1

TPL 数据流不启用并发或并行化(尽管您可以获得 ActionBlock 之类的东西来并行化其处理)，它是并发或并行代码用来传递数据的东西。除其他外，它是一种消息传递机制——这是共享数据的一种替代方法。共享数据，当被多个线程使用时需要昂贵的同步。如果处理得当，消息传递不需要同步，因为需要处理的数据被封装在一条消息中，该消息被“发送”到将处理它的代码。

如果您有特定设计，可以使用 TPL 数据流。如果您没有专门实现类似 Actor-based 的内容编程，或 message-passing ，或非阻塞生产者/消费者场景，那么 TPL 数据流可能会使事情复杂化。

如果您认为自己可能想要设计这样的系统，可以使用一些很好的资源来了解 TPL 数据流 (TDF)，例如 video Stephen Toub(微软平行团队成员)，以及 Dataflow MSDN page .

更新:

您可以为 block 设置最大并行度，但将其设置为高于 CPU 或核心数通常会适得其反。假设执行的每个操作都或多或少受 CPU 限制(在运行时使用 100% 的 CPU)。如果操作花费大量时间等待(等待等待句柄，等待消息泵中的消息——这对于操作来说是不正常的，但是对于 UI 威胁——等等)那么一定程度的并行性超出CPU 的数量可能有意义(尽管这很难调整)。当您确实运行的操作多于受 CPU 限制的 CPU 时，您就真正开始为操作系统分配任务了。操作系统希望将 CPU 时间分配给每个线程(或本例中的每个操作)，因为它正在“运行”。当没有足够的 CPU 运行时，操作系统开始抢占式多任务，轮询为每个事件线程提供 CPU 时间。每次操作系统将 CPU 从一个线程中拿走并将其交给另一个线程时，称为 context switching。 .这真的很贵(在 2000-8000 cpu cycles 的范围内)。因此，操作系统实际上将所有时间都花在了上下文切换上，而不是运行您的操作。

如果您的操作确实是异步的，那么 block 的并行度是无关紧要的，因为其他东西正在执行并行化。但是，同样的问题出现了，您的异步操作正在未经检查地执行，并且您冒着在您引入的上下文切换程度上压倒操作系统的风险。由于缺乏控制，我会认真考虑不执行异步操作。