实时嵌入式系统中的一种互斥方法 3000字

实时嵌入式系统中的一种互斥方法3000字多任务系统中当一个共享地址空间简单地用于数据交换时，为防止竞争，需要对内存的访问上锁，以保证访问互斥进行。实现资源互斥访问的办法很多，不同之处仅在于互斥的范围和程度。这些办法包括禁止中断，禁止抢占和使用信号量等对资源上锁。

互斥机制最强有力的办法是禁止中断，这种上锁保证了对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()

{

intOldPriority;

……//代码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)处有竞争条件，但