优先级反转

优先级反转

使用实时内核,优先级反转问题是实时系统中出现得最多的问题。例如在一个实时应用中，包含3个实时任务，任务1优先级最高，任务2其次，任务3优先级最低。任务1和任务2处于阻塞状态，等待某一事件的发生，任务3正在运行。下面是一个产生优先级反转问题的情况：

1. 开始时（时刻为 T1），任务3要使用共享资源 A。使用共享资源 A 之前，首先必须得到该资源的信号量(Semaphore)。假设任务3得到了该信号量，并开始使用该共享资源 A。
2. T2时，由于任务1优先级高，它等待的事件到来之后，会抢占任务3的 CPU 使用权，任务1开始运行。运行过程中任务1也要使用那个任务3正在使用着的资源 A，由于该资源的信号量还被任务3占用着，任务1只能进入阻塞状态，等待任务3释放该信号量。
3. T3时，任务3得以继续运行。由于任务2的优先级高于任务3，当任务2等待的事件发生后，任务2抢占了任务3的 CPU 的使用权并开始运行。处理它该处理的事件，直到处理完之后将 CPU 控制权还给任务3。
4. T4时，任务3接着运行，完成对共享资源 A 操作，释放信号量。
5. T5时，由于实时内核知道有个高优先级的任务在等待这个信号量，内核做任务切换，使任务1得到
   该信号量并接着运行。
   在这种情况下,任务1优先级实际上降到了任务3 的优先级水平。因为任务1要等,直等到任务3释放占有的共享资源。由于任务2抢占任务3的 CPU 使用权,使任务1的状况更加恶化,任务2使任务1增加了额外的延迟时间。任务1和任务2的优先级发生了反转。可以通过优先级继承(Priority inheritance)协议和优先级天花板（Priority Ceiling）协议解决优先级反转问题，但是这样会增加一些时间开销。RTEMS 支持优先级继承和优先级天花板方法。

在实时操作系统中，高优先级任务需要访问的资源被低优先级的任务占用，导致高优先级的任务被阻塞，高优先级任务必须等待低优先级任务释放资源后才能唤醒。如果这个低优先级的任务还被其他优先级中等的任务抢占了 CPU，那么优先级反转现象还有可能进一步恶化。因为低优先级任务无法继续，导致资源无法释放，高优先级的任务可能会被无限制延迟。RTEMS 采用了优先级继承算法和优先级天花板算法两种机制解决优先级反转问题

优先级继承算法

优先级继承是一种动态提高获得互斥共享资源的任务优先级的算法。如果获得互斥资源的任务由低优先级变为高优先级，那么中等优先级的任务就不会抢占该任务，也就不会导致需要同一资源的其他高优先级任务因为低优先级任务阻塞而出现不确定的时间。

RTEMS 为本地的二值信号量提供优先级继承算法。当高优先级任务因为低优先级占据资源而阻塞，那么占据资源的低优先级任务的优先级将会提升至此高优先级任务的优先级。当占据资源的任务释放信号量后，此任务的优先级将会恢复到原始状态。

RTEMS 优先级继承算法也考虑到了实时任务拥有多个资源的信号量这一情况。此时占据资源的任务的优先级将改变，新的优先级是所有阻塞任务的优先级的最小值（值越小，优先级越高）。只有当任务释放所有的信号量，他的优先级才恢复到原始水平。

优先级天花板算法

优先级天花板算法中，每个任务的优先级是已知的，每个任务要求的资源在执行前也是已知的。资源具有优先级，其优先级与预计要求占用此资源的任务中的最高优先级相同。要求占用资源的任务的优先级在得到资源后，会动态提升任务自身的优先级，新的优先级是任务此时所占用的所有资源中最高的资源优先级。该算法通过一次性改变任务优先级的方式解决任务优先级反转的问题（优先级继承算法中，每次有任务阻塞就可能需要改变一次优先级）。

RTEMS 为本地的二值信号量提供优先级天花板算法。当一个低优先级的任务获取资源的信号量，他的优先级会自动提高到资源的优先级天花板（Ceiling）的水平。该任务执行完对应的操作，释放了信号量，其优先级就会降低到原来的水平。

在大型实时应用系统中获取优先级天花板的操作将会很复杂。由于优先级天花板算法只用改变一次任务的优先级，所以比优先级继承算法更为高效。但是如果系统复杂，扫描将会占据信号量的所有任务的优先级同样也会降低执行效率。相对而言，优先级继承算法不需要预先获取任务的相关信息，所以也显得更为灵活。

RTEMS 的优先级天花板算法同样也适用于占据多个信号量的任务。 此时需要对每个二进制信号量分别进行优先级天花板算法，然后获取所有优先级天花板中的最高优先级（求两次最高优先级）。直到完成所有的对互斥资源的操作，他才会将优先级恢复到初始水平。还有一个需要注意的情况是，优先级继承算法不能防止死锁。优先级天花板算法可以，但是必须是在系统运行前知道所有任务对所有资源的访问情况。