Multithreading 理解协同程序

来自维基百科 该段指出：

。。。这意味着协同路由提供并发性，但不提供并行性

我知道协程比线程轻，不涉及上下文切换，没有关键部分，所以也不需要互斥。让我困惑的是，它的工作方式似乎无法扩展。根据维基百科，协同程序提供并发性，它们协同工作。带有协程的程序仍然按顺序执行指令，这与单核机器上的线程完全相同，但多核机器又如何呢？线程在其上并行运行，而协程的工作方式与单核机器上相同

我的问题是，协同程序在多核机器上的性能如何优于线程

…多核机器呢

协同路由是一种并发模型（其中两个或多个有状态的活动可以同时进行），但不是一种并行模型（在这种模型中，程序将能够使用比单个常规CPU核心所能提供的更多的硬件资源）

线程可以彼此独立运行，如果您的硬件支持它（即，如果您的机器有多个内核），那么两个或多个线程可以在同一时间执行其独立的活动

---

但根据定义，协同程序是相互依存的。一个协同路由只有在被另一个协同路由调用时才运行，并且调用方被挂起，直到当前协同路由将其回调。一组协同程序中只有一个协同程序可以在任何给定的时刻实际运行。

它们可能会或可能不会表现得更好，这取决于具体情况。如果有实际的工作要做的所有时间，他们不会比线程更好的大部分时间。如果它们相互依赖和/或顺序依赖，那么协同路由会更好。这是一个相当广泛的主题，没有更多的细节。他们的表现并不好。现在经常使用循环窃取线程池来实现。它们有不同的目标。协同路由主要用于任务负载公平性，线程用于两者：平衡负载和任务负载公平性，因此它们比协同路由更通用，但价格更高（上下文切换、同步原语）。关于“协同路由比线程轻”。我不会说“轻”协同程序和线程解决不同的问题。你能详细说明在什么情况下协同程序适合作为解决方案吗？为什么？我从来没有在任何实际项目中使用过协同程序。似乎当你有两个相互关联的、有状态的活动，并且没有明确的理由说明其中一个应该驱动另一个时，它们会很有用。我在学校记得的一个例子是词法分析器和解析器。lexer的顶层是一个循环，它从源文件中读取字符，并在每次构建完整令牌时“调用”解析器。同时，解析器有一个循环，每当它需要另一个令牌时，“调用”lexer。@neevek，它们通常用于各种UI任务（例如，当需要在某些游戏场景中移动大量对象时，使用线程来实现这一点是不切实际的）。另一个来自不同领域的非常著名的实现是.NET中

async/await

机制背后的状态机，其中

MoveNext

方法用作协同程序，并在异步流执行的不同阶段被调用。