为什么在不同的地方有许多schedule（）调用？

我正在跟踪Linux0.11

我看到在不同的地方有很多schedule（）调用，而不仅仅是dou timer（）中的调用

这里有几个问题：

每次计时器超时时都会调用do_timer（）（@sched.c）？此计时器基于x86中断调用

由于在do_timer（）之外有许多schedule（）调用，我能说这是一种抢占吗？或者目的是什么

---

阻止调用schedule（）以产生控制的任何操作

某些任务的状态已更改，需要在schedule（）中更新

有些任务正在工作，但仍有很多工作要做，请计划（）以实现平衡 由于在do_timer（）之外有许多schedule（）调用，我能说这是一种抢占吗？或者目的是什么

对于一个真正的操作系统；大多数任务切换发生的原因是任务阻塞等待某个内容（用户输入、网络数据包、磁盘IO等），或者任务取消阻塞是因为它等待的某个内容发生（并且取消阻塞的任务具有较高的优先级，并抢占当前正在运行的较低优先级的任务）

整个“由计时器IRQ引起的任务切换”事件主要只是防范恶意CPU占用（拒绝服务攻击）的一种回退；对于正常条件下的正常软件，您可以禁用它（从计时器IRQ处理程序中删除

schedule（）

），没有人会注意到或在意。注意：有些人会说它也适用于“非恶意”CPU绑定的任务，但CPU绑定的任务相对较少，而且（忽略Linux调度程序从来都不适合任务优先级的事实）对于CPU绑定的任务，最好依赖一个有效的任务优先级系统（例如，给CPU限制的任务一个低优先级，这样几乎所有任务都会抢占它们）

还要注意的是，关于操作系统理论的各种课程都是从“如此简单以至于在实践中永远不会发生”的概念开始的，这几乎总是一个纯粹的循环调度程序，任务永远不会阻塞（通常是“嘿，我们可以准确地预测未来，并且确切地知道每个任务将运行多长时间”这句话），作为第一步（以“先学走路再跑”的方式）基本上是不错的，但如果没有更现实、更复杂的概念（更好的调度算法、任务优先级、多个同步调度算法/调度策略、多CPU、交互式/延迟敏感任务等）的遵循，它会让人感觉很糟糕因为它只会给学生/受害者留下一些错误信息（例如，不断重复出现的“所有任务切换都是由计时器IRQ引起的”误解）

do_timer（）（@sched.c）将在每次计时器超时时调用？此计时器基于x86中断调用

我猜计时器是原始PIT芯片的IRQ（考虑到Linux版本0.11是“绝对的初学者开发人员，无意使其可移植”的历史纪念品，在数千名志愿者修复了一半最糟糕的部分之前）

另外，别忘了调度程序使用时间做两件事——“当前任务占用了太多的CPU时间”这件事几乎不重要，并且要弄清楚被阻止/休眠的任务（例如，因为它们调用了

sleep（）

）应该何时解除阻止/唤醒。

do\u timer（）

可能适用于这两种情况中的任何一种，也可能同时适用于这两种情况（我不看就不知道了）