调度程序是否确定哪些进程在被阻止后可以重新进入 CPU？
Does the scheduler determine which processes can re-enter the CPU after they're blocked?
我正在为我的 OS 期中学习而学习指南中有一个我不是 100% 确定的问题。
调度程序存在于：
一个。服务中断。
B.Select下一个进程进入CPU.
C. 新建一个进程。
D. 从系统中删除未使用的进程。
E.判断哪些被阻塞的进程可以进入CPU.
F.B 和 E.
所以我知道B(Select下一个进程进入CPU)是真的。
我不确定的部分是E选项。我不确定这到底意味着什么。
这是否实际上意味着在 scanf 之后需要用户输入并且进程保持阻塞的情况？
等待那个输入实际上意味着确定吗？或者调度程序是否主动参与确定是否输入了该输入？
你会怎么回答这个问题？ B 还是 F？
如果仔细查看进程状态，您会发现被阻塞的进程永远无法直接进入 CPU。只有当一个进程已经进入了就绪状态，才能进入CPU待执行
当进程处于 blocked/waiting 状态时，它基本上是在等待外部事件，例如来自用户的输入或在某些 I/O 设备队列中等待对于某些 I/O 服务。现在一旦该事件发生，它将进入 就绪 状态，调度程序（ 短期调度程序更准确 ）的工作是决定选择哪个进程在处于 ready 状态的那些中。所以语句E是错误的。
我正在为我的 OS 期中学习而学习指南中有一个我不是 100% 确定的问题。
调度程序存在于：
一个。服务中断。
B.Select下一个进程进入CPU.
C. 新建一个进程。
D. 从系统中删除未使用的进程。
E.判断哪些被阻塞的进程可以进入CPU.
F.B 和 E.
所以我知道B(Select下一个进程进入CPU)是真的。
我不确定的部分是E选项。我不确定这到底意味着什么。
这是否实际上意味着在 scanf 之后需要用户输入并且进程保持阻塞的情况？
等待那个输入实际上意味着确定吗？或者调度程序是否主动参与确定是否输入了该输入？
你会怎么回答这个问题？ B 还是 F？
如果仔细查看进程状态，您会发现被阻塞的进程永远无法直接进入 CPU。只有当一个进程已经进入了就绪状态，才能进入CPU待执行
当进程处于 blocked/waiting 状态时，它基本上是在等待外部事件，例如来自用户的输入或在某些 I/O 设备队列中等待对于某些 I/O 服务。现在一旦该事件发生，它将进入 就绪 状态，调度程序（ 短期调度程序更准确 ）的工作是决定选择哪个进程在处于 ready 状态的那些中。所以语句E是错误的。