协同调度与抢占式调度？

Question

在 Core Java：Volume 1 Fundamentals - ＆gt;一书中。章节MultiThreading 。

作者写道如下：

  

“所有现代桌面和服务器操作系统都使用抢先式   调度。但是，手机等较小的设备可能会使用   合作安排....“

我知道这两种类型的调度的定义/工作方式，但是想要理解为什么协作调度优先于小型设备中的抢占。

任何人都可以解释原因吗？

Answer 1

协同调度优先于抢先的一大好处是协同调度不使用“上下文切换”。上下文切换涉及存储和恢复应用程序（或线程）的状态。这很昂贵。

现在小型设备能够通过协同调度摆脱的原因与小型设备上只有一个用户的事实有关。协作调度的问题是一个应用程序可能占用CPU。在抢占式调度中，每个应用程序最终都有机会使用CPU几个周期。对于涉及多个恶魔或用户的大型系统，协作调度可能会导致问题。

减少上下文切换在现代编程中是一件大事。你可以在Node.js，Nginx，epoll，ReactiveX和许多其他地方看到它。

Answer 2

抢先式调度必须解决一个难题 - 从各种地方获取各种软件以有效地共享CPU。

协作调度解决了一个更简单的问题 - 允许在旨在协同工作的程序之间共享CPU。

因此，当你可以侥幸逃脱时，合作安排会更便宜，更容易。允许协同调度工作的小型设备的关键是所有软件都来自一个供应商，所有程序都可以设计为一起工作。

Answer 3

协作调度具有较少的同步问题。

协作调度可以在一些主要是人为的方案中获得更好的性能。

协同调度在线程的设计和实现上引入了约束。

由于可靠的I / O性能，协同调度对于大多数实际用途来说基本上是无用的，这就是为什么几乎没有人使用它。

即使是小型设备，如果它们可以侥幸逃脱，也会更喜欢使用抢占式计划。智能手机，流媒体（尤其是视频）以及需要良好I / O的此类应用程序对于协作系统来说基本上是不可能的。

您剩下的是琐碎的嵌入式烤箱控制器等。

Answer 4

首先，您必须找到抢占

一词的含义

抢占是暂时中断计算机系统正在执行的任务而无需其配合，目的是在以后恢复该任务的行为。执行任务的这种更改称为上下文切换。（https://en.wikipedia.org/wiki/Preemption_(computing)）

因此，区别是

• 在抢先模型中，操作系统的线程调度程序是 允许介入并将控制权从一个线程转移到另一个线程 时间（可以强制中止任务）。

• 在合作伙伴模型中，一旦线程获得控制权，它将继续 运行直到它明确产生控制权（将CPU的控制权移交给下一个任务）或阻塞为止。

两个模型都有其优点和缺点。当CPU必须运行彼此不相关的各种软件时，抢先式调度会更好地工作。当运行旨在协同工作的程序时，协同调度的效果更好。

合作调度线程的示例：

1. Windows光纤（https://docs.microsoft.com/en-gb/windows/win32/procthread/fibers?redirectedfrom=MSDN）
2. 索尼的PlayStation 4 SDK（http://twvideo01.ubm-us.net/o1/vault/gdc2015/presentations/Gyrling_Christian_Parallelizing_The_Naughty.pdf）

如果您想学习这些协作调度光纤的下划线实现，请参阅本书（https://www.gameenginebook.com/）

您的书指出“可能是诸如手机之类的较小设备”可能是几年前提到的手机。他们只有少数几个要运行的程序，并且全部由电话制造商提供。因此，我们可以假定这些程序是旨在协同工作的。

Answer 5

硬实时控制应用程序通常要求至少一个线程/任务不能抢先地中断，而其他线程则更为宽容。此外，最高优先级的任务可能要求严格的计划执行，而不是任由最终将提供时隙的计划程序处理。对于这些应用程序，协作式多任务处理似乎比抢占式多任务处理更接近需要的内容，但是它仍然不完全适合，因为某些任务可能需要立即按需中断响应，而其他任务对多任务处理方案则较不敏感。 / p>

Answer 6

协作调度 任务将在称为（同步点）的点上放弃 CPU。它可以在 POSIX 中使用类似的东西：

• pthread.yield(Task_ID)

抢占式调度 这里的主要区别在于，在抢占式调度中，任务可能会被调度程序强制放弃 CPU。例如，两个优先级相同的任务，其中一个在运行时，它的时间片就结束了。