最大并发限制答案

【问题标题】：Maximum Concurrency Throttle最大并发限制
【发布时间】：2012-01-15 19:51:32
【问题描述】：

我希望这个问题有很多可能的解决方案，我自己可以提出一些解决方案，其中一些明显优于其他解决方案，但我确定没有一个是最佳解决方案，因此我很想听听您真正的多线程专家的意见.

我有大约 100 件可以同时执行的工作，因为它们之间没有依赖关系。如果我按顺序执行这些，我的总执行时间约为 1:30 秒。如果我将线程池中的每一项工作排队，大约需要 2m，这表明我试图一次做太多事情，所有这些线程之间的上下文切换正在否定拥有这些线程的优势。

因此，基于这样的假设（如果这是错误的，请随时将我击落），如果我在任何时候只排队我系统中的核心数量（这台机器上的 8 个）工作件，我将减少上下文切换，从而提高整体效率（当然，其他进程线程无法承受），谁能提出最佳模式/技术来做到这一点？

顺便说一句，我正在使用 smartthreadpool.codeplex.com，但我不必这样做。

【问题讨论】：

我不知道“智能”线程池，但它应该尽量保持#thread 低。 std ThreadPool 表现如何？
SmartThreadPool 嗯？为什么要在 .net ThreadPool 上使用它完全是个谜。你能启发我吗？
它有一些很好的语法糖，我以前用过，没有其他原因。从未比较/研究过它如何与 .NET 本机实现相抗衡，因此现在正在将其换掉..
我记得好几年前的SmartThreadPool，记得它非常好。它和框架是如何保持同步的，以及在哪些情况下，我不能说。
而且升级框架版本并非总是不可能的，所以我认为沿着 4.0 行的答案值得包括在混合中，以及那些与 3.5 保持一致的答案。如果不出意外，他们可以帮助除 OP 之外的其他人）。

标签： c# .net multithreading .net-3.5

【解决方案1】：

一个好的线程池已经尝试让每个可用核心拥有一个活动线程。这不是每个内核都有一个线程工作的问题，就好像一个线程正在阻塞（最典型的是在 I/O 上），您希望另一个线程使用该内核。

尝试 .NET 线程池或 Parallel 类可能值得一试。

如果您的 CPU 是超线程的（4 个物理内核上的 8 个虚拟内核），这可能是个问题。平均而言，超线程使事情变得更快，但在很多情况下它会使事情变得更糟。尝试为每个其他内核设置亲和力，看看它是否会给您带来改进 - 如果确实如此，那么这很可能是超线程不好的情况。

您是否必须再次将结果收集在一起，或者在不同任务之间共享任何资源？这样做的成本可能比多线程节省的成本要高。也许它们是如此不必要 - 例如如果您锁定共享数据但该数据仅被读取，则您实际上不需要使用大多数数据结构进行读取（如果没有写入，大多数但并非全部对于并发读取都是安全的）。

工作的划分也可能是一个问题。假设单线程方法通过一个内存区域工作，但多线程方法为每个线程提供下一个内存位以使用循环。这里每个核心会有更多的缓存刷新，因为“好下一位”实际上正在被另一个核心使用。在这种情况下，将工作分成更大的块可以解决它。

还有很多其他因素可以使多线程方法的性能比单线程方法更差，但我可以立即想到这些。

编辑：如果您正在写入共享存储，则可能值得尝试一次运行，您只需丢弃所有结果。这可能会缩小问题所在的范围。

【讨论】：

【解决方案2】：

对我来说，你所说的似乎很奇怪。因为根据定义，线程池的使用不应超过系统拥有的可用资源（即，如果您有 4 个内核，它将使用 4 个线程或接近这个数字的东西）。它使用一个队列，工作线程从中获取任务并执行它们。因此，如果您使用线程池，则无法真正实现系统超额订阅，除非您手动指定要使用的线程数，在您的情况下不建议这样做。

您是否尝试过改用标准 C# ThreadPool 类？

【讨论】：

线程池并不总是完美地让每个核心始终拥有一个线程，因为这通常需要每个核心超过 1 个线程在线程阻塞时完成工作，但要增加多少并不总是容易预测的。我同意他们应该尝试标准池进行比较。
@Jon Hanna：我同意，这个数字并不总是完美的，但达到比顺序执行时间慢的仍然很奇怪。
这一切都说得通，并且是我最初的假设，但并不能解释为什么在并发执行时整体工作需要更长的时间。我将换出智能线程池，并将每件工作模拟为受计算限制的工作，而不是受 IO 限制且可能会干扰我的结果的实际工作。