摘要：本文分析了实时嵌入式操作系统中几种常用的互斥方法，提出了一种基于任务优先级的禁止抢占法，并分析了该方法的安全性和高效性。
关键词：多任务 任务优先级 抢占 调度时机 调度器
A EXCLUSIVE METHOD OF THE REAL-TIME EMBED OPERATING SYSTEMAbstract Some common-used exclusive methods are analyzed in this paper.It advances a no preemptive method which based on task priority and analyzes the security and high-efficiency.
Keywords Multitask Task priority Preemptive Scheduling chance Scheduler
1 引言
多任务系统中当一个共享地址空间简单地用于数据交换时，为避免竞争，需要对内存的访问上锁，以保证访问互斥进行。实现资源互斥访问的方法很多，不同之处仅在于互斥的范围和程度。这些方法包括禁止中断，禁止抢占和使用信号量等对资源上锁。
互斥机制最强有力的方法是禁止中断，这种上锁保证了对CPU的独占访问。在互斥期间，即使外部事件产生而引发相应的中断，系统也不会切换到相应的中断服务程序(ISR)，也能保证任务之间的互斥。因此在上锁期间，它可能造成系统对外部事件反应迟钝。这对于大多数实时系统而言，系统的实时性也就得不到保证，因而不适合作为一种通用的互斥方法。然而当涉及到任务和中断服务程序共享数据时，中断上锁又是唯一的方法。但是在任何情况下，应该使中断上锁时间尽量短，这也是所有实时系统的基本要求。
从本质上讲，信号量机制比禁止中断或禁止抢占提供更精确的互斥粒度，但是在使用时需要注意优先级继承，删除安全性和递归使用等问题，并且当一个任务需要同时获取多个信号量时更要注意避免系统的死锁问题。因此，一般实时嵌入式操作系统都会为用户提供多种互斥手段，以适应不同的使用场合。但对于禁止抢占（禁止调度）这种方法而言，有些系统支持，如UC/OS--II，VxWorks等，而有些系统未必支持，如PSOS等，为了达到禁止抢占这种效果，并且不受具体系统的约束，本文提出了一种新的禁止抢占方法——最高优先级法。
2 禁止抢占的基本原理
如果任务不与中断服务子程序共享变量或数据结构，可以使用先禁止然后允许任务切换的手段。此时虽然任务切换禁止了，但中断还是开着的。如果这时中断来了，中断服务子程序会在这一临界区内立即执行。中断服务子程序结束时，即使有更高优先级的任务已经进入就绪态，内核还是返回到原先被中断了的任务，直到执行完给任务切换开锁函数，内核再看看有没有优先级更高的任务被中断服务子程序激活而进入就绪态，如果有则做任务切换。此种机制比中断上锁要弱一些。
3 最高优先级法
3．1最高优先级法的基本原理
在实时嵌入式系统中，各个应用任务依据实时性.重要性被赋予了不同的优先级，内核严格按照优先级的高低来调度任务，高优先级的任务能抢占低优先级的任务以满足实时性的要求。另外，实时嵌入式操作系统一般都提供了动态更改任务优先级的系统调用。我们可以将系统中的最高优先级(HiPriority)预留下来，当某任务需要禁止抢占时，将该任务的优先级提升到最高优先级(PriorityProtect)，在该任务将其自身的优先级设回原优先级(UnPriorityProtect)之前，系统中的其它任务不会抢占该任务，该任务可以放心地完成临界区的操作。使用这种方法也可以选择基于优先级的时间片轮转调度。轮转调度可以使优先级相同处于就绪态的任务公平地分享使用CPU。按照优先级调度的原理，考察我们的最高优先级法：当任务处于最高优先级时即使时间片到期任务也不会切换出去，因为就绪队列里优先级最高(为HiPriority)的任务只有一个，不管它是否用完时间片，其它低优先级的任务都无法抢占它。
3．2最高优先级法的普通实现
我们先来分析下面的一种在实际开发工作中会遇到的情况，任务A中有一段临界区代码，并且假设该临界区代码不包含因等待资源而不得不让出CPU的可能：
PriorityProtect()；
……//代码1
Func()；//函数调用
……//代码2
UnPriorityProtect()；
而函数Func()如下定义：
Func()
{
……//代码3
PriorityProtect()；
……//代码4
UnPriorityProtect()；
……//代码5
}
当Func()执行完时，任务A的优先级被设回了原先的优先级，代码2将受不到保护!因此，我们需要对函数PriorityProtect()和UnPriorityProtect()进行改造：函数PriorityProtect()需返回设置最高优先级之前任务的优先级，而函数UnPriorityProtect()却不一定总是设置任务原先的优先级，它设置的是与之配对的PriorityProtect()返回的优先级。这两个函数都是成对使用的，不管嵌套使用了多少次都不会出错，举例如下：
OldPriority=PriorityProtect()；
……//代码1
Func()；//函数调用
……//代码2
UnPriorityProtect(OldPriority)；
而函数Func()如下定义：
Func()
{
int OldPriority;
……//代码3
OldPriority =PriorityProtect()；
……//代码4
UnPriorityProtect(OldPriority)；
……//代码5
}
这样在函数Func()执行完后任务仍处于最高优先级状态，代码2仍受到保护，符合程序员的意图，程序员不必担心会发生意外。但是这种方法的效率有点低下，执行Func()时已经是最高优先级状态了，却还要再设置，浪费了CPU时间，在嵌套次数较多时效率问题将更加严重。另一方面我们不能轻易将函数Func()中的互斥手段去掉，因为这要考虑在其它没提供互斥手段的情况下调用Func()。基于上述原因，我们引入一种高效的方法——嵌套计数法。
3．3最高优先级法的嵌套计数实现
先来定义操作规则：COUNT为系统中的全局变量，初始化为0。
PriorityProtect()
{
if(!COUNT) ……(1)
利用具体的系统调用把当前任务设成最高优先级 ……(2)
COUNT++； ……(3)
}
UnPriorityProtect()
{
COUNT--；……(4)
if(!COUNT) ……(5)
利用具体的系统调用把当前任务设成原先的优先级……(6)
}
再来分析一下这种方法的安全性。COUNT是全局变量，对它的访问要防止竞争条件。但巧妙的是一旦我们把任务用操作系统原语调用设成最高优先级后，信捷职称论文写作发表网，对COUNT的访问将是独占的；一个任务首次调用PriorityProtect()时在语句(1)处有竞争条件，但一次只能有一个任务通过(2)处的原语成为最高优先级，只要我们正确地配对使用这两个函数，当这个任务最终退出最高优先级状态时COUNT必为0，并不影响其它任务在(1)处的判断。这种方法的高效性也是明显的，在嵌套使用的里层仅仅进行嵌套计数的计算，并不用进行优先级的设置。
4 结论
尽管不同的实时嵌入式操作系统给用户提供的系统调用接口不尽相同，但是它们所准遵循的基本原理都是相同的。上述关于禁止任务抢占的普通实现以及嵌套计数实现提供的都是实现思想，在实际应用中很容易结合所使用的具体的操作系统写出PriorityProtect()和UnPriorityProtect()的实现代码。
[1] Labrosse Jean J，uc/OS-II-源码公开的实时嵌入式操作系统，邵贝贝译，北京：中国电力出版社，2001.
[2] 孔祥营等，嵌入式实时操作系统VxWorks及其开发环境Tornado，北京：中国电力出版社，2001.
