控制任务的实际并发答案

【问题标题】：Controlling actual concurrency with tasks控制任务的实际并发
【发布时间】：2016-10-05 10:00:08
【问题描述】：

在某些情况下，我希望能够在使用任务时控制实际并发。

一个很好的例子是编写一个小型客户端来负载测试服务器端 API。在这种情况下，我希望随时有 X 个并发请求。

现在，如果我使用 TPL ，我只能设置 max degree of parallelism ，这是不一样的。我考虑过使用长时间运行的任务，但从我读到的内容不推荐：

当然我可以使用线程而不是任务，但是如果有使用 TPL 实现实际并发的选项，我会更喜欢它。

【问题讨论】：

这里有很多混乱。首先，您为什么关心处理的最小请求数？如果您的机器足够快，您可能不必同时运行您认为的那么多任务。其次，没有什么可以阻止您指定确切的数字，例如使用Parallel.For 和特定的DOP，例如10。您不必在任何地方都使用Task，它只是一个原语。最后，处理消息/请求流的最佳选择是来自 TPL Dataflow 的ActionBlock<T>。您可以指定同时处理的消息数。
ActionBlock 文档展示了如何创建具有特定 DOP 的 ActionBlock 并向其发布消息。您还可以将多个块链接到管道中（称为网格）
谢谢，我看不出这个问题有什么令人困惑的地方。无论我的程序运行多快，我都希望能够精确控制并发。在负载测试中，您经常希望在任何给定时间有 X 个并发调用。根据我的测试 DOP in Parallel.For 也不能控制实际的并发性。我将阅读有关 ActionBlock 的更多信息，看看它是否有帮助。
我也看不出 ActionBlock 在这个场景中会有什么帮助。它可能仍然构建在其他 TPL 结构之上，因此使用 DOP ，这不能保证对并行度的精确控制。见：msdn.microsoft.com/en-us/library/hh228609(v=vs.110).aspx

【解决方案1】：

如果您想直接控制运行特定代码的线程数，则不应使用 TPL。 TPL 在后台进行了优化，例如任务内联和工作窃取。即使您设法同时获得正确数量的线程，您也可能不会产生预期的负载量。特别是如果任务花费大部分时间等待，例如在 http 或 wcf 请求中。

一个信号量可能就足够了。

【讨论】：