进程在任何给定时间的状态由正在执行的进程组成，对吗？所以目前说有 4 个用户空间程序在处理器上运行。现在在每个时间片之后，我假设必须将控制权传递给调度程序，以便接下来可以调度适当的进程。是什么引发了这种控制权的转移？对我来说，硬件中似乎必须有某种特殊的计时器/寄存器来计算进程当前所用的时间，因为进程本身没有机制来跟踪它执行的时间......我的直觉对吗？
【问题讨论】：
Is my intuition right??部分，硬件定时器发起中断，由OS处理，在这个handler中可以调度线程/进程执行，这个定时器对线程一无所知，OS知道
标签： linux-kernel operating-system scheduling
首先，这个答案仅涉及 x86 架构。
有不同种类的调度器：抢占式和非抢占式（合作）。
抢占式调度器 抢占进程的执行，即使用TSS（Task State Segment）发起上下文切换，然后执行跳转到另一个进程.该进程已停止并启动另一个进程。
协作调度程序不会停止进程。它们依赖于进程，该进程放弃 CPU 以支持调度程序，也称为“yielding”，类似于没有内核支持的用户级线程。
可以通过两种方式实现抢占：作为某些 I/O 绑定操作的结果或在 CPU 运行时。
想象一下，您向 FPU 发送了一些指令。它需要一些时间才能完成。您可以在 FPU 执行计算的同时做其他事情，而不是无所事事！因此，作为 I/O 操作的结果，调度程序切换到另一个进程，可能会在 FPU 完成后立即恢复被抢占的进程。
然而，许多调度算法所要求的定期抢占只能通过某种中断机制来实现，该中断机制以一定的频率发生，与进程无关。计时器芯片被认为是合适的，并且在 1981 年发布的 IBM 5150（又名 IBM PC）中，交付了 x86 系统，其中包括 Intel 8086、Intel 8042 键盘控制器芯片、Intel 8259 PIC（可编程中断控制器） ) 和 Intel 8253 PIT（可编程间隔定时器）。
i8253 与其他一些外围设备一样连接到 i8259。在一秒钟内几次（18 Hz？），它在 IRQ 0 上向 PIC 发出 #INT 信号，在确认后，所有 CPU 都被中断并执行了一个处理程序。 该处理程序可能包含调度代码，它决定下一个要执行的进程1。
当然，我们（我们大多数人）现在生活在 21st 世纪，没有 IBM PC 或其衍生产品之一，例如使用的 XT 或 AT。 PIC 已更改为更复杂的 Intel 82093AA APIC 以处理多个处理器/内核并进行总体改进，但我认为 PIT 保持不变，可能是像 Intel AIP 这样的集成版本。
协作调度程序不需要定期中断，因此不需要特殊的硬件支持（可能除了硬件支持的多任务处理）。该过程故意产生CPU，如果没有，你就有问题了。很少有操作系统真正使用协作调度器的原因是：它带来了很大的安全漏洞。
1 但是请注意，8086 上的操作系统（主要是 DOS）并没有真正的 调度器。 x86 架构仅原生支持多任务处理 80386 版本（SX、DX 等）之一的出现。我只是想强调一下，IBM 5150 是第一个带有计时器芯片的 x86 系统（当然，也是第一台 PC）。
【讨论】：
运行具有抢占式调度程序的操作系统（即所有常用的）的系统都是 IME，都提供了一个硬件定时器中断，该中断导致驱动程序运行并可以更改运行线程集。
这样的定时器中断对于为系统调用、sleep() 功能和其他与时间相关的函数提供超时非常有用。当系统过载时，它还可以帮助在就绪线程之间共享可用的 CPU，或者在其上运行的线程是 CPU 密集型的，因此就绪线程的数量超过了可用于运行它们的内核数量。
很可能在没有任何硬件计时器的情况下实现抢占式调度程序，允许在软件中断（系统调用）、已经运行的线程以及所有其他中断时调度正在运行的线程集。 O 完成磁盘、NIC、KB、鼠标等的外围驱动程序。虽然我从未见过它完成 - 计时器功能太有用了:)
【讨论】：