performance - 上下文切换的价格是多少？与依靠OS线程相比，实现手动任务切换是否更好？

Question

想象一下，我有两个(三个，四个或其他)任务必须并行运行。现在，执行此操作的简单方法是创建单独的线程并忽略它。但是在一个普通的老式单核CPU上，这意味着要进行大量上下文切换-我们都知道上下文切换既大，坏，慢又通常只是Evil。应该避免吧？

关于这一点，如果我还是从头开始编写软件，那么我可以加倍努力并实现自己的任务切换。将每个任务拆分为多个部分，保存它们之间的状态，然后在一个线程中在它们之间切换。或者，如果我检测到有多个CPU内核，则可以将每个任务分配给一个单独的线程，一切都会好起来的。

第二种解决方案确实具有适应可用CPU内核数量的优势，但是手动任务切换真的会比OS内核中的任务切换速度更快吗？特别是如果我想通过TaskManager和ITask等使整个事情变得通用吗？

澄清:我是Windows开发人员，所以我主要是对此操作系统的答案感兴趣，但同时了解其他操作系统也将是最有趣的。写下答案时，请注明答案。

更多说明:好，因此这不在特定应用程序的上下文中。这确实是一个普遍的问题，这是我对可伸缩性的沉思。如果我想让我的应用程序扩展并有效利用 future 的CPU(甚至是当今的不同CPU)，则必须使其成为多线程的。但是有多少个线程？如果我使用恒定数量的线程，则该程序将在所有内核数量不相同的CPU上性能欠佳。

理想情况下，线程数将在运行时确定，但是很少有可以在运行时真正拆分为任意数量的部分的任务。但是，在设计时，许多任务可以拆分为相当大数量的恒定线程。因此，例如，如果我的程序可以产生32个线程，那么它将已经利用了多达32核CPU的所有核，这在 future 还很遥远(我认为)。但是在简单的单核或双核CPU上，这意味着要进行大量上下文切换，这会使事情变慢。

因此，我对手动任务切换的想法。这样一来，可以创建32个“虚拟”线程，这些线程将被映射到最佳数量的实际线程，并且“上下文切换”将手动完成。问题是-手动“上下文切换”的开销是否会小于OS上下文切换的开销？

自然，所有这些都适用于受CPU限制的进程，例如游戏。对于您的常规CRUD应用程序，这没有什么值(value)。最好使用一个线程(最多两个)来创建这样的应用程序。

Answer 1

我看不到手动任务切换的速度如何更快，因为OS内核仍在切换其他进程，包括您的进程也都处于运行状态。似乎是过早的优化，可能会浪费大量的精力。

如果系统没有执行任何其他操作，则您无论如何都不会有大量的上下文切换。该线程将使用其时间片，内核调度程序将看到不需要运行其他任何内容并立即切换回您的线程。而且，操作系统将尽最大努力避免在CPU之间移动线程，因此您可以从中受益。

如果您确实受CPU限制，请检测CPU的数量并启动那么多线程。您应该看到接近100％的CPU利用率。如果不是这样，您就不会完全受CPU限制，也许答案是启动N + X线程。对于受IO约束的进程，您将启动CPU数量的(较大)倍数(即，高流量的Web服务器运行1000多个线程)。

最后，作为引用，Windows和Linux调度程序都每毫秒唤醒一次，以检查是否需要运行另一个进程。因此，即使在闲置的系统上，您也将每秒看到1000多个上下文切换。在高负载的系统上，我看到每个CPU每秒超过10,000，而没有任何重大问题。