现在，设置线程关联性而不是将其留给操作系统的理由是什么？

Question

在这里搜索“线程亲和力”的答案，我看到很有兴趣这样做，但没有理由，除了可能获得稳定的QueryPerformanceTimer结果。

假设现代操作系统和现代2-4插槽工作站/服务器级机器具有现代4-6核心CPU，那么有什么理由认为他们比操作系统的调度程序更清楚？是否有任何现实世界的情况，更多地控制thead亲和力是正确的事情？可以证明什么样的性能优势？

上次我看到一个非常好的案例来设置线程亲和性（例如，它由具体结果支持，显示系统性能的真正和显着改进），这与Win2K设备驱动程序有些模糊不清。但是我多年没见过这样的东西，所以当有人告诉我他们需要控制线程亲和力（但不是为什么）这些天我对此深表怀疑......但是很想表现出来。

Answer 1

主要原因是，如果您在缓存时拥有依赖重的内容。操作系统调度程序不一定考虑到您可能喜欢的程度。

Answer 2

我用它来分配线程到核心;例如，在模拟中，您完全在一个核心上执行物理，并允许其余计算在另一个核心上执行。如果你在一个熟悉硬件的环境中，能够控制它是有意义的。

当然，配置这个需要按系统完成，所以默认情况下我让操作系统决定运行的核心，但保留限制核心使用的选项。

Answer 3

在OS内核中，有时在内核模式驱动程序中，您需要在每个CPU上执行相同的操作（例如，更新系统寄存器）。您可以在单个线程的循环中执行此操作，从而更改每次迭代的关联。

Answer 4

对于台式机，这是非常不必要的。

但我可以看到一些有用的应用程序。例如，如果在其上运行的应用程序没有更改，CPU缓存就会喜欢它。

另一种可能性是你有一个关键任务 - 你给它一个完整的CPU，其他任务使用其余的CPU。

或相反：你有一些低优先级的任务，你把它们全部放在一个CPU上，然后让其他人自由地完成更重要的任务（使用进程优先级会给你带来大部分好处而没有亲和力，但我可以想象一些记忆沉重的情况，它不会）。

Answer 5

我同意最好留给CPU来解决大多数情况。但是，就我所见，最常见的寻求线程亲和性的原因是当你需要良好的缓存依赖性时。在多CP​​U系统中，当一个特定的CPU为自己单独缓存某些东西，并且如果在其他CPU中缓存了相同的东西，那么我相信它可以在另一个CPU上自动失效。因此，如果特定线程不断更改其执行的CPU，则缓存命中率将会降低。所以在这种情况下，我想程序员可以更好地判断COU的亲和力。 我还认为Ariel关于确保关键任务不断获得CPU而不限制其他低优先级进程的上述观点也是有道理的。