uCOS-II 基础入门教程(三）

任务优先级

每个任务都有其优先级。任务越重要，赋予的优先级应越高。

静态优先级

应用程序执行过程中诸任务优先级不变，则称之为静态优先级。

 动态优先级

应用程序执行过程中，任务的优先级是可变的，则称之为动态优先级。实时内核应当避免出现优先级反转问题。

 优先级反转

如图，任务1优先级高于任务2，任务2优先级高于任务3。任务1和任务2处于挂起状态，等待某一事件的发生，任务3正在运行如。此时，任务3要使用其共享资源。使用共享资源之前，首先必须得到该资源的信号量(Semaphore)。任务3得到了该信号量，并开始使用该共享资源。由于任务1优先级高，它等待的事件到来之后剥夺了任务3的CPU使用权，任务1开始运行。运行过程中任务1也要使用那个任务3正在使用着的资源，由于该资源的信号量还被任务3占用着，任务1只能进入挂起状态，等待任务3释放该信号量。任务3得以继续运行。由于任务2的优先级高于任务3，当任务2等待的事件发生后，任务2剥夺了任务3的CPU的使用权并开始运行。处理它该处理的事件，直到处理完之后将CPU控制权还给任3。任务3接着运行，直到释放那个共享资源的信号量。直到此时,由于实时内核知道有个高优先级的任务在等待这个信号量，内核做任务切换，使任务1得到该信号量并接着运行。

在这种情况下,任务1优先级实际上降到了任务3 的优先级水平。因为任务1要等,直等到任务3释放占有的那个共享资源。由于任务2剥夺任务3的CPU使用权,使任务1的状况更加恶化,任务2使任务1增加了额外的延迟时间。任务1和任务2的优先级发生了反转。

纠正的方法可以是,在任务3使用共享资源时,提升任务3的优先级。任务完成时予以恢复。任务3的优先级必须升至最高,高于允许使用该资源的任何任务。多任务内核应允许动态改变任务的优先级以避免发生优先级反转现象。然而改变任务的优先级是很花时间的。如果任务3并没有先被任务1剥夺CPU使用权，又被任务2抢走了CPU使用权,花很多时间在共享资源使用前提升任务3的优先级,然后又在资源使用后花时间恢复任务3的优先级,则无形中浪费了很多CPU时间。真正需要的是,为防止发生优先级反转,内核能自动变换任务的优先级,这叫做优先级继承(Priority inheritance)但μC/OS-Ⅱ不支持优先级继承。

 

下图：优先级继承过程。任务3在运行,任务3申请信号量以获得共享资源使用权，任务3得到并开始使用共享资源。后来CPU使用权被任务1剥夺，任务1开始运行，任务1申请共享资源信号量。此时,内核知道该信号量被任务3占用了,而任务3的优先级比任务1低,内核于是将任务3的优先级升至与任务1一样,,然而回到任务3继续运行,使用该共享资源,直到任务3释放共享资源信号量。这时,内核恢复任务3本来的优先级并把信号量交给任务1,任务1得以顺利运行。,任务1完成以后那些任务优先级在任务1与任务3之间的任务例如任务2才能得到CPU使用权,并开始运行。

 

 任务优先级分配

给任务定优先级可不是件小事，因为实时系统相当复杂。许多系统中，并非所有的任务都至关重要。不重要的任务自然优先级可以低一些。实时系统大多综合了软实时和硬实时这两种需求。软实时系统只是要求任务执行得尽量快，并不要求在某一特定时间内完成。硬实时系统中，任务不但要执行无误，还要准时完成。

单调执行率调度法RMS(Rate Monotonic Scheduling),用于分配任务优先级。这种方法基于哪个任务执行的次数最频繁,执行最频繁的任务优先级最高。

 

 

uCOS-II 基础入门教程链接如下：

uCOS-II 基础入门教程（二）

uCOS-II 基础入门教程（一）

关注微信公众号“嵌入式软件开发学习圈”，获取更多学习资料、以及资讯。你们的关注是我最大动力。