有人可以解释一下编写在具有单核的单个处理器上运行的多线程代码是否真的有任何优势？例如，一种处理文档页面的方法，使得这些页面与上述代码段互斥。
乍一看，这似乎没有优势，因为真正的多线程是不可能的。即，操作系统无论如何都必须上下文切换线程。我想知道是否仅以单线程方式编写代码实际上会更有效。
显然，在很多情况下编写多线程代码是有意义的，但我的问题是，当应用程序在单核处理器上运行时，这样做是否真的有好处。
编辑：请注意，我没有说“应用程序”而是“一段代码” - 看看我上面的例子。显然，拥有多线程应用程序有很多好处。
仍然有优势，但它们有点情境化。
在许多情况下，赋予事物多个线程将允许它从其他进程中获取更多系统资源。这对平衡很挑剔，并且您引入的每个线程都会增加一些开销，但这可能是一个原因。
如果您正在处理多个潜在的阻塞资源——比如文件 IO 或 GUI 交互等等，那么多线程可能是至关重要的。
是的，多线程在单核中很有用。如果应用程序中的一个线程在等待某事（比如来自网卡的数据或等待磁盘写入数据）时被阻塞，CPU 可以切换到另一个线程以继续工作。
BeOS 在编写时考虑到了普遍的多线程，即使在单核处理器时代也是如此。结果是一个响应速度非常快的操作系统，尽管它是一个相当难以编程的操作系统。
在单核处理器上，使用异步（非阻塞）I/O 的应用程序将比使用多个阻塞线程的应用程序效率稍高一些，因为它避免了线程之间上下文切换的开销。
此外，异步 I/O 的扩展性比线程中的阻塞 I/O 更好，因为与创建新线程的开销相比，每次额外 I/O 操作的开销是最小的。
话虽如此，您通常不应在新应用程序中使用单线程异步 I/O，因为几乎所有新处理器都是多核的。相反，您仍应使用异步 I/O，但使用线程池之类的东西将工作分配给一组工作线程。您的系统文档会告诉您理想的工作线程数；通常它等于可用的处理核心数。
编辑：至少在 Windows 平台上，.NET 中的 async/await 模式是执行异步 I/O 的现代方式。它使这种模式与旧的阻塞 I/O 模式一样容易编写。现在几乎没有理由写阻塞 I/O。