【RTOS】调度

抢占调度

Figure 4-6中，优先级较低的任务T2不会延迟优先级较高的任务T1的调度。

不可抢占调度

Figure 4-7中，优先级较低的任务T2会延迟优先级较高的任务T1，直到下一次重新调度点（在本例中为任务T2的终止）。

优先级反转

Figure 8-1展示了两个任务对一个信号量进行访问时的调度顺序（在一个完全抢占式系统中，任务T1具有最高优先级）。

1. 优先级较低的任务T4占用了信号量S1。
2. T1抢占T4并请求访问同一个信号量。
3. 由于信号量S1已被占用，T1进入等待状态。
4. 此时，优先级较低的T4被中断，并被优先级介于T1和T4之间的任务抢占。
5. 只有在所有优先级较低的任务都已终止，并且信号量S1再次释放后，T1才能被执行。
6. 尽管T2和T3并未使用信号量S1，但它们的运行时间却延迟了T1的执行。

死锁

Figure 8-2以下场景会导致死锁

1. 任务T1占用了信号量S1，随后无法继续运行，例如因为它正在等待某个事件。
2. 因此，优先级较低的任务T2被切换到运行状态。它占用了信号量S2。
3. 如果T1再次准备就绪并试图占用信号量S2，它将再次进入等待状态。
4. 如果此时T2尝试占用信号量S1，就会导致死锁。

天花板优先级解决 优先级反转问题

Figure 8-3所示的示例说明了优先级上限机制的工作原理。

1. 任务T0具有最高优先级，而任务T4具有最低优先级。
2. 任务T1和任务T4想要访问相同的资源。
3. 系统清楚地表明，这不会导致无界的优先级反转。
4. 高优先级任务T1等待的时间比任务T4占用资源的最长时间要短。

figure 8-4

1. 可抢占任务T1正在运行，并请求与中断服务例程INT1共享的资源。
2. 任务T1激活了优先级更高的任务T2和T3。
3. 由于OSEK优先级上限协议的存在，任务T1仍在继续运行。
4. 此时发生了中断INT1。由于OSEK优先级上限协议，任务T1仍然在运行，因此中断INT1被挂起。接着发生了中断INT2。
5. 中断服务例程INT2中断了任务T1并开始执行。 INT2执行完毕后，任务T1继续运行。
6. 任务T1释放了资源。随后，中断服务例程INT1被执行，任务T1再次被中断。 INT1执行完毕后，任务T3开始运行。
7. 任务T3结束后，任务T2开始运行。任务T2结束后，任务T1继续运行。

figure 8-5

1. 可抢占任务T1正在运行。发生了中断INT1。
2. 任务T1被中断，并且执行了中断服务程序INT1。
3. INT1请求了一个与中断服务程序INT2共享的资源。
4. 此时发生了优先级更高的中断INT2。
5. 由于OSEK优先级上限协议（Priority Ceiling Protocol）的存在，INT1仍在继续执行，而INT2则处于挂起状态。
6. 接着发生了中断INT3。 由于INT3的优先级高于INT1，它中断了INT1的中断服务程序并开始执行。
7. INT3激活了任务T2。 在INT3执行完毕后，INT1继续执行。
8. 当INT1释放了所请求的资源后，由于INT2的优先级高于INT1，因此INT2得以执行。 在INT2执行完毕后，INT1继续执行。
9. 当INT1执行完毕后，由于任务T2的优先级高于任务T1，任务T2开始运行，而任务T1则处于就绪状态。
10. 在任务T2终止后，任务T1继续执行。