中断与进程调度的关系及操作系统相关机制疑问

问题1：中断是否必然引发进程调度及切换？若不是，哪些类型的中断会触发进程调度？对于不触发调度的中断，中断后原进程处于五状态进程模型中的何种状态？为何该状态下不进入进程队列触发调度？ #

• 中断不是必然引发进程调度和切换。
• 会触发进程调度的中断类型：
  • 时钟中断：当进程的时间片耗尽时，操作系统会触发调度，选择下一个就绪进程执行。
  • I/O完成中断：比如磁盘读取完成、网络数据到达，原本等待该I/O的进程会从等待态转为就绪态，此时操作系统可能会触发调度，判断是否需要切换到这个就绪进程。
  • 系统调用中断：比如进程调用sleep()、wait()进入阻塞态，或者调用exit()终止，这类情况会触发调度来选择新的进程占用CPU。
• 不触发调度的中断处理完成后，原进程处于运行状态。这类中断通常是处理时间极短、不影响原进程继续执行的场景，比如单个按键输入的键盘中断（仅把字符存入缓冲区，无需改变进程状态）、轻微的硬件错误中断（如浮点运算下溢，系统快速处理后不影响进程运行）。原进程不需要进入就绪队列，因为它的时间片还没耗尽，也没有进入阻塞状态，直接恢复运行能减少调度带来的额外开销，提升系统效率。

问题2：调用C语言sleep函数后进程进入等待状态，定时器到期后进入就绪状态，若CPU未立即调度该进程，是否会超出设定的定时时长？此外，多线程程序中，一个线程传输文件，另一个线程等待用户输入以取消传输，若取消线程未在CPU上运行，如何及时响应输入并终止传输？是否源于优先级调度与抢占机制？ #

• 关于sleep的定时时长：sleep(n)指定的是进程至少等待n秒，实际唤醒时间大概率会超过设定值。因为定时器到期后进程只是进入就绪队列，若此时CPU正在运行其他高优先级进程、或者当前进程还在执行临界区无法被抢占，就需要等待。操作系统无法保证精确的唤醒时间，这是多任务系统的正常现象。
• 关于多线程的输入响应：用户输入会触发键盘硬件中断，操作系统处理这个中断时，会把输入事件通知给等待输入的取消线程，将其从等待态转为就绪态。此时如果系统是抢占式调度，操作系统会立刻检查是否有更高优先级的就绪线程（如果取消线程优先级高于传输线程），或者当前进程的时间片是否允许抢占，一旦满足条件就会触发进程切换，让取消线程获得CPU执行，从而及时终止传输。核心是中断触发了操作系统的调度介入，抢占机制是及时响应的关键，优先级调度则是辅助提升响应速度的手段。

内容的提问来源于stack exchange，提问作者suubai