22

我目前正在开发一个依赖于许多不同 Web 服务来获取数据的应用程序。由于我想模块化每个服务并在其中有一点依赖性（service1 必须在服务 2 和 3 之前运行等），所以我在自己的任务中运行每个服务。

任务本身要么

  1. 正在积极运行，这意味着他们正在将请求发送到 Web 服务并正在等待响应或处理响应

  2. 等待（通过监视器和超时） - 一旦任务完成，所有等待的任务都会唤醒并检查它们的依赖关系是否已经完成

现在，系统正在以我称之为良好性能的方式运行（尤其是因为性能相当可忽略不计）——但是，应用程序会生成相当多的任务。

所以，我的问题是：在这种情况下~200 个任务太多了吗？它们是否会产生那么多开销，从而使基本上无线程的方法会更好？

4

1 回答 1

19

一般的答案是“测量、测量、测量”:) 如果您没有遇到任何性能问题，则不应开始优化。

不过我会说200个任务很好。与线程相比，任务的美妙之处在于它们与“真实”线程甚至线程池相比开销较低。TaskScheduler 确保以最少的线程切换量尽可能多地利用所有硬件线程。它通过各种技巧来做到这一点，例如串行运行子任务、从其他线程的队列中窃取工作等等。

您还可以通过TaskCreationOptions为 TaskScheduler 提供一些关于特定任务将要执行的操作的提示

如果您想要一些数字，请查看这篇文章，如您所见，Tpl 在开销方面非常便宜：
.NET 4.0 - 任务并行库 (TPL) 的性能，作者 Daniel Palme

这是关于该主题的另一篇有趣的文章：
CLR Inside Out：使用并发实现可伸缩性，作者：Joe Duffy

于 2013-10-13T17:42:05.297 回答