我试图绕过协作多任务系统的概念以及它在单线程应用程序中的工作原理。
我的理解是，这是“多任务处理的一种形式，其中多个任务通过在每个任务中由程序员定义的点自愿将控制权让给其他任务来执行。”
因此，如果您有一个任务列表并且一个任务正在执行，您如何确定将执行传递给另一个任务？当您将执行返回到之前的任务时，如何从之前的位置恢复？
我觉得这有点令人困惑，因为我不明白如果没有多线程应用程序如何实现这一点。
任何建议都会很有帮助:)
谢谢
【问题讨论】：
标签： multitasking
在单个进程（或执行线程）使用协作多任务处理的特定场景中，您可以使用诸如 Windows 的纤程或 POSIX setcontext 系列函数之类的东西。我将在这里使用术语纤维。
基本上，当一个纤程完成执行一大块工作并希望自愿允许其他纤程运行（因此称为“合作”术语）时，它要么手动切换到另一个纤程的上下文，要么更典型地执行某种产量() 或 scheduler() 调用会跳转到调度器的上下文中，然后调度器会找到要运行的新纤程并切换到该纤程的上下文。
这里的上下文是什么意思？基本上是堆栈和寄存器。堆栈没有什么神奇之处，它只是堆栈指针恰好指向的一块内存。程序计数器也没有什么神奇之处，它只是指向下一条要执行的指令。切换上下文只是将当前寄存器保存在某处，将堆栈指针更改为不同的内存块，将程序计数器更新为不同的指令流，将该上下文保存的寄存器复制到 CPU 中，然后进行跳转。 Bam，您现在正在使用不同的堆栈执行不同的指令。通常，上下文切换代码是用汇编编写的，它以不修改当前堆栈或撤销更改的方式调用，在任何一种情况下，它都不会在堆栈或寄存器中留下任何痕迹，因此当代码恢复执行时，它具有不知道发生了什么。 （再次，主题：我们假设方法调用摆弄寄存器，将参数推送到堆栈，移动堆栈指针等，但这只是 C 调用约定。没有什么需要你维护一个堆栈或有任何特定的方法调用在堆栈上留下任何自己的痕迹）。
由于每个堆栈都是独立的，因此您不会有一些看似随机的方法调用的连续链最终溢出堆栈（如果您天真地尝试使用连续相互调用的标准 C 方法来实现此方案，这可能是结果） .您可以使用状态机手动实现这一点，其中每个纤程都保存其工作位置的状态机，定期返回调用调度程序的方法，但是当实际纤程/协程支持广泛可用时，为什么还要麻烦呢？
还请记住，协作式多任务处理与进程、受保护内存、地址空间等是正交的。例如 Mac OS 9 或 Windows 3.x。他们支持分离流程的想法。但是当您让步时，上下文更改为操作系统上下文，允许操作系统调度程序运行，然后可能选择另一个进程切换到。从理论上讲，您可以拥有一个仍然使用协作多任务处理的完全受保护的虚拟内存操作系统。在那些系统中，如果一个错误的进程永远不会让步，那么操作系统调度程序就永远不会运行，因此系统中的所有其他进程都会被冻结。 **
下一个自然的问题是什么使某些事情先发制人...答案是操作系统与 CPU 调度一个中断计时器来停止当前正在执行的任务并切换回操作系统调度程序的上下文，而不管当前任务是否关心是否释放 CPU，从而“抢占”它。 如果操作系统使用 CPU 特权级别，则（内核配置的）定时器不能被较低级别（用户模式）代码取消，尽管理论上如果操作系统不使用此类保护，错误的任务可以屏蔽或取消中断定时器和劫持CPU。还有一些其他场景，例如 IO 调用，其中可以在计时器之外调用调度程序，并且调度程序可能会决定没有其他进程具有更高的优先级并将控制权返回给同一进程而无需切换......实际上大多数操作系统不会在这里做一个真正的上下文切换，因为这很昂贵，调度程序代码运行在任何正在执行的进程的上下文中，所以必须非常小心不要踩到堆栈，保存寄存器状态等。
** 你可能会问，如果在某个时间段内没有调用 yield，为什么不直接触发一个计时器。答案在于多线程同步。在合作系统中，您不必费心去锁、担心重新进入等，因为您只在事情处于已知良好状态时才会让步。如果这个神秘的计时器触发了，那么您现在可能已经破坏了被中断程序的状态。如果必须编写程序来处理这个问题，恭喜……你现在拥有了一个半途而废的先发制人的多任务系统。还不如做对了！而且，如果您无论如何都要进行更改，不妨添加线程、受保护的内存等。这几乎就是主要操作系统的历史。
【讨论】：
协作式多任务处理的基本理念是信任——每个子任务将自行及时放弃控制，以避免占用其他任务的处理器时间。这就是为什么协作式多任务系统中的任务需要极其彻底地测试，并且在某些情况下需要经过认证才能使用的原因。
我不自称是专家，但我认为协作任务可以实现为状态机，将控制权传递给任务会使其运行绝对最少时间它需要取得任何进展。例如，文件读取器可能会读取文件的下几个字节，解析器可能会解析文档的下一行，或者传感器控制器可能会读取一次，然后将控制权返回给协作调度程序，该调度程序将检查任务完成。
每个任务都必须将其内部状态保留在堆上（在对象级别），而不是像传统的阻塞函数或线程那样在堆栈帧（在函数级别）上。
与依赖硬件计时器来触发上下文切换的传统多任务处理不同，协作多任务处理依赖于以这样一种方式编写代码，即每个长时间运行的任务的每一步都保证在可接受的小范围内完成时间。
【讨论】：
任务将执行显式的 wait 或 pause 或 yield 操作，从而调用调度程序。在繁重的计算中，可能有不同的操作等待 IO 完成或显式让步。在应用程序任务的主循环中，它可以有一个 *wait_for_event* 调用而不是忙轮询。这将暂停任务，直到它有输入要处理。
也可能有一种超时机制来捕获失控任务，但它不是主要的切换方式（否则它不会合作）。
【讨论】：
考虑协作式多任务处理的一种方法是将任务拆分为步骤（或状态）。每个任务都会跟踪它需要执行的下一步。轮到任务时，它只执行那一步并返回。这样，在程序的主循环中，您只是按顺序调用每个任务，并且因为每个任务只占用少量时间来完成一个步骤，我们最终得到一个允许所有任务执行的系统共享 cpu 时间（即合作）。
【讨论】：