据我所知，当我执行 Parallel.For 和类似构造之类的东西时，TPL 使用工作窃取队列来执行其任务。
如果我理解正确的话，该构造将启动许多任务，每个任务将开始处理项目。如果其中一个任务完成了分配给他们的物品，它将开始从其他尚未完成的任务中窃取物品。这解决了以下问题：项目 1-100 的处理成本较低，而项目 101-200 的处理成本较高，并且两个任务之一将处于闲置状态，直到另一个任务完成。 （我知道这是一个简化的解释。）
但是，这将如何在终端服务器或 Web 应用程序中扩展（假设我们在将在 Web 应用程序中运行的代码中使用 TPL）？我们是否可以仅仅因为有 N 个并行运行的应用程序实例而冒使 CPU 充满任务的风险？
我应该阅读有关该主题的任何信息吗？我还没有发现任何特别的东西，但这并不意味着没有。
您也许能够使用 TPL 通过迁移到异步模型来改进 I/O 绑定操作。您还可以通过在低负载情况下更多地利用 Web 服务器上可用的未使用处理器容量来改善请求延迟。您需要仔细考虑这一点，因为在高负载下，处理器已经 100% 使用，增加更多并行性将降低服务器的吞吐量。
并行扩展团队博客对此进行了讨论：
在 ASP.NET 应用程序中使用 .NET 4 的并行扩展 http://blogs.msdn.com/pfxteam/archive/2010/02/08/9960003.aspx
我怀疑同样的论点也适用于终端服务器应用程序。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
