我正在阅读以下链接中的实时概念
http://www.embeddedlinux.org.cn/RTConforEmbSys/5107final/LiB0024.html
这里在4.4.4节中提到了
调度程序是执行上下文的调度程序的一部分 切换并改变执行流程。任何时候RTOS都是 运行，执行流程，也称为控制流程，是 通过三个方面之一：通过一个应用程序任务， 通过ISR，或通过内核。当任务或ISR成为 系统调用，控制流传递给内核执行一个 内核提供的系统例程。什么时候到 离开内核，调度员负责传递控制权 到用户应用程序中的任务之一。它不一定 与进行系统调用的任务相同。
这是调度算法（稍后将讨论） 调度程序，确定接下来执行哪个任务。它是 执行上下文切换和传递的实际工作的调度程序 执行控制。
根据内核首次输入的方式，可能会发生调度 不同。当任务进行系统调用时，调度程序习惯 每次系统调用完成后退出内核。在这种情况下， 调度程序用于逐个呼叫，以便它可以协调 任何系统调用可能具有的任务状态转换 造成的。 （例如，一个或多个任务可能已准备好运行。）
另一方面，如果ISR进行系统调用，则调度程序是 绕过，直到ISR完全执行完毕。这个过程是 即使某些资源已被释放，通常也是如此 触发任务之间的上下文切换。这些上下文切换不会 发生的原因是ISR必须完成而不会被中断 任务。 ISR完成执行后，内核退出 调度程序，以便它可以调度正确的任务
。
我对上述文字的质询是
谢谢！
答案 0 :(得分：3)
作者提供了一个实时系统架构的简化说明，其中控制线程可以处于三种状态之一 - 内核模式（系统调用），应用程序模式（TASK）或中断服务例程（ISR）模式。
此示例中的调度程序是一个内核例程，它在退出其中一个应用程序TASK发出的每个系统调用后决定要接收控制的应用程序TASK。这可能是发出系统调用的TASK，也可能是不同的TASK，具体取决于所遵循的调度算法和规则。
基于系统的计划使用，调度规则和算法有很多变化;作为一个例子，您可能会想到每个TASK每分钟都有相同的CPU时间 - 因此，如果正在执行3个应用程序任务，则每个应该每分钟接收20秒的CPU时间。在这种情况下，调度程序可以决定接收控制的下一个TASK是在最后一分钟内累计CPU时间最少的TASK，以尝试在TASKS上平均分配每分钟的CPU时间。
在决定下一次接收控制的TASK之后，调度员将退出系统调用模式并将控制转移到应用程序TASK，因此调用调度程序相当于＆＃34;退出＆＃34;内核并将控制转移到符合条件的应用程序TASK。
作者指出，这是实时系统，这意味着将重点放在应用程序处理（TASKS）上的中断（通过ISR）的快速处理。为了最小化ISR发出系统调用时每个中断所消耗的时间，内核将直接返回到该ISR而不是通过调度程序退出＃34;这将允许控制应用程序TASK。
当ISR完成其处理时，其退出将以导致内核调用调度程序的方式执行（因此它将通过调度程序退出），因此应用程序TASK可以再次使用CPU。
作为补充说明：此解释中隐藏的假设之一是应用程序TASKS和中断服务例程（ISR）可以调用相同的内核例程（系统调用）。这很常见，但安全性和性能问题可能需要ISR和TASKS的不同内核例程（系统调用）。
答案 1 :(得分：1)
系统调用完成后，必须将控制权传递回用户空间任务。可能有许多用户空间任务等待运行，它们可能具有不同的优先级。调度员使用它的算法根据优先级和其他标准评估等待任务（等待多长时间？我预计他们需要多长时间？）然后启动其中一个。
例如，您可能有一个需要从命令行读取输入的应用程序。因此，您的应用程序调用read（）系统调用，该调用将控制权传递给内核。 read（）完成后，调度程序将评估等待运行的任务，并可能决定运行另一个任务而不是调用read（）的任务