Operating system 操作系统如何一次处理多个设备？

当有多个设备同时工作时，操作系统面临哪些挑战？哪些可以用来帮助确定处理这些设备的顺序？

对于设备驱动程序和设备，通常（作为基本/简化模型）：

• 某些东西（使用CPU）要求设备驱动程序要求其设备执行某种工作，导致设备驱动程序的代码运行
• 设备驱动程序的代码检查设备当前是否忙，如果设备忙，驱动程序将新作业放入某种“挂起作业队列”并返回。如果设备不忙；然后设备驱动程序告诉它的设备该做什么，然后返回。无论哪种方式，设备驱动程序都会很快返回（CPU会返回到运行正常代码的状态，等等）
• 然后（稍后）设备发回一个IRQ，表示它（成功或不成功）完成了所要求的操作，导致CPU再次运行设备驱动程序代码
• 然后，设备驱动程序代码检查先前工作的状态，并执行任何需要的操作（将状态通知任何请求的作业，传输任何接收到的数据等）
• 然后，设备驱动程序检查“挂起作业队列”上是否有其他作业。如果有一个，它将被删除，并且驱动程序要求设备在从IRQ返回之前执行该操作。无论哪种方式，驱动程序都会从IRQ返回（CPU会再次运行正常代码）

这里重要的一点是，设备驱动程序只使用很少的CPU时间来管理设备（而设备大部分时间都在做它被告知要做的事情，而不使用任何CPU）；而且几乎所有CPU的时间都可以花在做其他事情上（包括花一点时间管理许多其他设备，花很多时间运行正常的用户空间代码）。这意味着许多不同的设备可以同时做有用的事情，而CPU/s将大部分时间用于执行普通代码

通常只有两件事可以管理订单。首先是如何设计设备驱动程序的“待处理作业队列”。它可以是一个简单的“先到先得”FIFO队列；但通常更复杂的是涉及“IO优先级”（例如，确保在从同一设备预取实际不需要的数据之前，从交换空间读取急需的数据）

用于管理订单的第二件事是IRQ优先级（当多个设备同时/类似地生成IRQ时）。这可以是“先到先得”（不管理IRQ的处理顺序），也可以涉及硬件支持和操作系统合作

警告1：这是一个基本/简化的模型。在实际系统中，存在更多的复杂性（例如，设备驱动程序的“待处理作业队列”中已经存在的作业可以取消，设备驱动程序必须进行电源管理，设备可能可以拔出，等等）；一些设备有自己的内部队列和/或能够自己同时执行多个作业

---

警告2：这是“典型的现代操作系统”。操作系统是不同的，一些操作系统（例如30年前的MS-DOS）可能不会执行上述操作（并且可能根本不允许同时使用多个设备）。

对于设备驱动程序和设备，通常（作为基本/简化模型）：

• 某些东西（使用CPU）要求设备驱动程序要求其设备执行某种工作，导致设备驱动程序的代码运行
• 设备驱动程序的代码检查设备当前是否忙，如果设备忙，驱动程序将新作业放入某种“挂起作业队列”并返回。如果设备不忙；然后设备驱动程序告诉它的设备该做什么，然后返回。无论哪种方式，设备驱动程序都会很快返回（CPU会返回到运行正常代码的状态，等等）
• 然后（稍后）设备发回一个IRQ，表示它（成功或不成功）完成了所要求的操作，导致CPU再次运行设备驱动程序代码
• 然后，设备驱动程序代码检查先前工作的状态，并执行任何需要的操作（将状态通知任何请求的作业，传输任何接收到的数据等）
• 然后，设备驱动程序检查“挂起作业队列”上是否有其他作业。如果有一个，它将被删除，并且驱动程序要求设备在从IRQ返回之前执行该操作。无论哪种方式，驱动程序都会从IRQ返回（CPU会再次运行正常代码）

这里重要的一点是，设备驱动程序只使用很少的CPU时间来管理设备（而设备大部分时间都在做它被告知要做的事情，而不使用任何CPU）；而且几乎所有CPU的时间都可以花在做其他事情上（包括花一点时间管理许多其他设备，花很多时间运行正常的用户空间代码）。这意味着许多不同的设备可以同时做有用的事情，而CPU/s将大部分时间用于执行普通代码

通常只有两件事可以管理订单。首先是如何设计设备驱动程序的“待处理作业队列”。它可以是一个简单的“先到先得”FIFO队列；但通常更复杂的是涉及“IO优先级”（例如，确保在从同一设备预取实际不需要的数据之前，从交换空间读取急需的数据）

用于管理订单的第二件事是IRQ优先级（当多个设备同时/类似地生成IRQ时）。这可以是“先到先得”（不管理IRQ的处理顺序），也可以涉及硬件支持和操作系统合作

警告1：这是一个基本/简化的模型。在实际系统中，存在更多的复杂性（例如作业）