【RTOS】调度
抢占调度
Figure 4-6中，优先级较低的任务T2不会延迟优先级较高的任务T1的调度。
不可抢占调度
Figure 4-7中，优先级较低的任务T2会延迟优先级较高的任务T1，直到下一次重新调度点（在本例中为任务T2的终止）。
优先级反转
Figure 8-1展示了两个任务对一个信号量进行访问时的调度顺序（在一个完全抢占式系统中，任务T1具有最高优先级）。
- 优先级较低的任务T4占用了信号量S1。
- T1抢占T4并请求访问同一个信号量。
- 由于信号量S1已被占用，T1进入等待状态。
- 此时，优先级较低的T4被中断，并被优先级介于T1和T4之间的任务抢占。
- 只有在所有优先级较低的任务都已终止，并且信号量S1再次释放后，T1才能被执行。
- 尽管T2和T3并未使用信号量S1，但它们的运行时间却延迟了T1的执行。
死锁
Figure 8-2以下场景会导致死锁
- 任务T1占用了信号量S1，随后无法继续运行，例如因为它正在等待某个事件。
- 因此，优先级较低的任务T2被切换到运行状态。它占用了信号量S2。
- 如果T1再次准备就绪并试图占用信号量S2，它将再次进入等待状态。
- 如果此时T2尝试占用信号量S1，就会导致死锁。
天花板优先级解决 优先级反转问题
Figure 8-3所示的示例说明了优先级上限机制的工作原理。
- 任务T0具有最高优先级，而任务T4具有最低优先级。
- 任务T1和任务T4想要访问相同的资源。
- 系统清楚地表明，这不会导致无界的优先级反转。
- 高优先级任务T1等待的时间比任务T4占用资源的最长时间要短。
figure 8-4
- 可抢占任务T1正在运行，并请求与中断服务例程INT1共享的资源。
- 任务T1激活了优先级更高的任务T2和T3。
- 由于OSEK优先级上限协议的存在，任务T1仍在继续运行。
- 此时发生了中断INT1。由于OSEK优先级上限协议，任务T1仍然在运行，因此中断INT1被挂起。接着发生了中断INT2。
- 中断服务例程INT2中断了任务T1并开始执行。 INT2执行完毕后，任务T1继续运行。
- 任务T1释放了资源。随后，中断服务例程INT1被执行，任务T1再次被中断。 INT1执行完毕后，任务T3开始运行。
- 任务T3结束后，任务T2开始运行。任务T2结束后，任务T1继续运行。
figure 8-5
- 可抢占任务T1正在运行。发生了中断INT1。
- 任务T1被中断，并且执行了中断服务程序INT1。
- INT1请求了一个与中断服务程序INT2共享的资源。
- 此时发生了优先级更高的中断INT2。
- 由于OSEK优先级上限协议（Priority Ceiling Protocol）的存在，INT1仍在继续执行，而INT2则处于挂起状态。
- 接着发生了中断INT3。 由于INT3的优先级高于INT1，它中断了INT1的中断服务程序并开始执行。
- INT3激活了任务T2。 在INT3执行完毕后，INT1继续执行。
- 当INT1释放了所请求的资源后，由于INT2的优先级高于INT1，因此INT2得以执行。 在INT2执行完毕后，INT1继续执行。
- 当INT1执行完毕后，由于任务T2的优先级高于任务T1，任务T2开始运行，而任务T1则处于就绪状态。
- 在任务T2终止后，任务T1继续执行。
RTOS相关 文章被收录于专栏
调度 中断
