2.0          前后台系统 （Foreground/Background System）... 1

2.1          代码的临界段... 2

2.2          资源... 2

2.3          共享资源... 2

2.4          多任务... 2

2.5          任务... 2

2.6          任务切换(Context Switch or Task Switch). 3

2.7          内核（Kernel）... 3

2.8          调度（Scheduler）... 4

2.9          不可剥夺型内核 （Non-Preemptive Kernel）... 4

2.10        可剥夺型内核... 5

2.11        可重入性（Reentrancy）... 5

2.12        时间片轮番调度法... 7

2.13        任务优先级... 7

2.14        2.14静态优先级... 7

2.15        动态优先级... 7

2.16        优先级反转... 7

2.17        任务优先级分配... 8

2.18        互斥条件... 10

2.18.1         关中断和开中断... 10

2.18.2         测试并置位... 11

2.18.3         禁止,然后允许任务切换... 11

2.18.4         信号量(Semaphores). 12

2.19        死锁(或抱死)（Deadlock (or Deadly Embrace)）... 16

2.20        同步... 16

2.21        事件标志(Event Flags). 18

2.22        任务间的通讯(Intertask Communication). 18

2.23        消息邮箱(Message Mail boxes). 18

2.24        消息队列(Message Queue). 19

2.25        中断... 20

2.26        中断延迟... 20

2.27        中断响应... 21

2.28        中断恢复时间(Interrupt Recovery). 21

2.29        中断延迟、响应和恢复... 22

2.30        中断处理时间... 22

2.31        非屏蔽中断(NMI). 23

2.32        时钟节拍(Clock Tick). 24

2.33        对存储器的需求... 25

2.34        使用实时内核的优缺点... 26

2.35        实时系统小结... 26

 

第2章         实时系统概念
实时系统的特点是，如果逻辑和时序出现偏差将会引起严重后果的系统。有两种类型的实时系统：软实时系统和硬实时系统。在软实时系统中系统的宗旨是使各个任务运行得越快越好，并不要求限定某一任务必须在多长时间内完成。

       在硬实时系统中，各任务不仅要执行无误而且要做到准时。大多数实时系统是二者的结合。实时系统的应用涵盖广泛的领域，而多数实时系统又是嵌入式的。这意味着计算机建在系统内部，用户看不到有个计算机在系统里面。以下是一些嵌入式系统的例子：

       通讯类

       Switch Hurb

       路由器

机器人

航空航天

       飞机管理系统

武器系统

喷气发动机控制

民用消费品

       微波炉

       洗碗机

       洗依机

稳温调节器
 
过程控制

       食品加工

       化工厂

汽车业

       发动机控制

       防抱死系统(ABS)

办公自动化

       传真机

       复印机

计算机外设

       打印机

       计算机终端

扫描仪

调制解调器
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

实时应用软件的设计一般比非实时应用软件设计难一些。本章讲述实时系统概念。

2.0         前后台系统   （Foreground/Background System）
       不复杂的小系统一般设计成如图2.1所示的样子。这种系统可称为前后台系统或超循环系统(Super-Loops)。应用程序是一个无限的循环，循环中调用相应的函数完成相应的操作，这部分可以看成后台行为(background)。中断服务程序处理异步事件，这部分可以看成前台行为（foreground）。后台也可以叫做任务级。前台也叫中断级。时间相关性很强的关键操作(Critical operation)一定是靠中断服务来保证的。因为中断服务提供的信息一直要等到后台程序走到该处理这个信息这一步时才能得到处理，这种系统在处理信息的及时性上，比实际可以做到的要差。这个指标称作任务级响应时间。最坏情况下的任务级响应时间取决于整个循环的执行时间。因为循环的执行时间不是常数，程序经过某一特定部分的准确时间也是不能确定的。进而，如果程序修改了，循环的时序也会受到影响。

图2-1前后台系统

 

       很多基于微处理器的产品采用前后台系统设计，例如微波炉、电话机、玩具等。在另外一些基于微处理器的应用中，从省电的角度出发，平时微处理器处在停机状态(halt)，所有的事都靠中断服务来完成。

2.1         代码的临界段
       代码的临界段也称为临界区，指处理时不可分割的代码。一旦这部分代码开始执行，则不允许任何中断打入。为确保临界段代码的执行，在进入临界段之前要关中断，而临界段代码执行完以后要立即开中断。(参阅2.03共享资源)

2.2         资源
       任何为任务所占用的实体都可称为资源。资源可以是输入输出设备，例如打印机、键盘、显示器，资源也可以是一个变量，一个结构或一个数组等。

2.3         共享资源
       可以被一个以上任务使用的资源叫做共享资源。为了防止数据被破坏，每个任务在与共享资源打交道时，必须独占该资源。这叫做互斥（mutual exclusion）。在2.18节“互斥”中，将对技术上如何保证互斥条件做进一步讨论。

2.4         多任务
       多任务运行的实现实际上是靠CPU(中央处理单元)在许多任务之间转换、调度。CPU只有一个，轮番服务于一系列任务中的某一个。多任务运行很像前后台系统，但后台任务有多个。多任务运行使CPU的利用率得到最大的发挥，并使应用程序模块化。在实时应用中，多任务化的最大特点是，开发人员可以将很复杂的应用程序层次化。使用多任务，应用程序将更容易设计与维护。

2.5         任务
       一个任务，也称作一个线程，是一个简单的程序，该程序可以认为CPU完全只属该程序自己。实时应用程序的设计过程，包括如何把问题分割成多个任务，每个任务都是整个应用的某一部分，每个任务被赋予一定的优先级，有它自己的一套CPU寄存器和自己的栈空间(如图2.2所示)。

图2.2多任务。

       典型地、每个任务都是一个无限的循环。每个任务都处在以下5种状态之一的状态下，这5种状态是休眠态，就绪态、运行态、挂起态(等待某一事件发生)和被中断态（参见图2.3）                 休眠态相当于该任务驻留在内存中，但并不被多任务内核所调度。就绪意味着该任务已经准备好，可以运行了，但由于该任务的优先级比正在运行的任务的优先级低，还暂时不能运行。运行态的任务是指该任务掌握了CPU的控制权，正在运行中。挂起状态也可以叫做等待事件态WAITING，指该任务在等待，等待某一事件的发生，（例如等待某外设的I/O操作，等待某共享资源由暂不能使用变成能使用状态，等待定时脉冲的到来或等待超时信号的到来以结束目前的等待，等等）。最后，发生中断时，CPU提供相应的中断服务，原来正在运行的任务暂不能运行，就进入了被中断状态。图2.3表示μC/OS-Ⅱ中一些函数提供的服务，这些函数使任务从一种状态变到另一种状态。

图2.3任务的状态

2.6         任务切换(Context Switch or Task Switch)
    Context Switch 在有的书中翻译成上下文切换，实际含义是任务切换，或CPU寄存器内容切换。当多任务内核决定运行另外的任务时，它保存正在运行任务的当前状态（Context），即CPU寄存器中的全部内容。这些内容保存在任务的当前状况保存区（Task’s Context Storage area），也就是任务自己的栈区之中。（见图2.2）。入栈工作完成以后，就是把下一个将要运行的任务的当前状况从该任务的栈中重新装入CPU的寄存器，并开始下一个任务的运行。这个过程叫做任务切换。任务切换过程增加了应用程序的额外负荷。CPU的内部寄存器越多，额外负荷就越重。做任务切换所需要的时间取决于CPU有多少寄存器要入栈。实时内核的性能不应该以每秒钟能做多少次任务切换来评价。

2.7         内核（Kernel）
    多任务系统中，内核负责管理各个任务，或者说为每个任务分配CPU时间，并且负责任务之间的通讯。内核提供的基本服务是任务切换。之所以使用实时内核可以大大简化应用系统的设计，是因为实时内核允许将应用分成若干个任务，由实时内核来管理它们。内核本身也增加了应用程序的额外负荷，代码空间增加ROM的用量，内核本身的数据结构增加了RAM的用量。但更主要的是，每个任务要有自己的栈空间，这一块吃起内存来是相当厉害的。内核本身对CPU的占用时间一般在2到5个百分点之间。

    单片机一般不能运行实时内核，因为单片机的RAM很有限。通过提供必不可缺少 的系统服务，诸如信号量管理，邮箱、消息队列、延时等，实时内核使得CPU的利用更为有效。一旦读者用实时内核做过系统设计，将决不再想返回到前后台系统。

2.8         调度（Scheduler）
    调度（Scheduler）,英文还有一词叫dispatcher，也是调度的意思。这是内核的主要职责之一，就是要决定该轮到哪个任务运行了。多数实时内核是基于优先级调度法的。每个任务根据其重要程度的不同被赋予一定的优先级。基于优先级的调度法指，CPU总是让处在就绪态的优先级最高的任务先运行。然而，究竟何时让高优先级任务掌握CPU的使用权，有两种不同的情况，这要看用的是什么类型的内核，是不可剥夺型的还是可剥夺型内核。

2.9         不可剥夺型内核     （Non-Preemptive Kernel）
不可剥夺型内核要求每个任务自我放弃CPU的所有权。不可剥夺型调度法也称作合作型多任务，各个任务彼此合作共享一个CPU。异步事件还是由中断服务来处理。中断服务可以使一个高优先级的任务由挂起状态变为就绪状态。但中断服务以后控制权还是回到原来被中断了的那个任务，直到该任务主动放弃CPU的使用权时，那个高优先级的任务才能获得CPU的使用权。

    不可剥夺型内核的一个优点是响应中断快。在讨论中断响应时会进一步涉及这个问题。在任务级，不可剥夺型内核允许使用不可重入函数。函数的可重入性以后会讨论。每个任务都可以调用非可重入性函数，而不必担心其它任务可能正在使用该函数，从而造成数据的破坏。因为每个任务要运行到完成时才释放CPU的控制权。当然该不可重入型函数本身不得有放弃CPU控制权的企图。

    使用不可剥夺型内核时，任务级响应时间比前后台系统快得多。此时的任务级响应时间取决于最长的任务执行时间。

    不可剥夺型内核的另一个优点是，几乎不需要使用信号量保护共享数据。运行着的任务占有CPU，而不必担心被别的任务抢占。但这也不是绝对的，在某种情况下，信号量还是用得着的。处理共享I/O设备时仍需要使用互斥型信号量。例如，在打印机的使用上，仍需要满足互斥条件。图2.4示意不可剥夺型内核的运行情况，任务在运行过程之中，[L2.4(1)]中断来了，如果此时中断是开着的，CPU由中断向量[F2.4(2)]进入中断服务子程序，中断服务子程序做事件处理[F2.4(3)]，使一个有更高级的任务进入就绪态。中断服务完成以后，中断返回指令[F2.4(4)], 使CPU回到原来被中断的任务，接着执行该任务的代码[F2.4(5)]直到该任务完成，调用一个内核服务函数以释放CPU控制权，由内核将控制权交给那个优先级更高的、并已进入就绪态的任务[F2.4(6)]，这个优先级更高的任务才开始处理中断服务程序标识的事件[F2.4(7)]。   

图2.4不可剥夺型内核

    不可剥夺型内核的最大缺陷在于其响应时间。高优先级的任务已经进入就绪态，但还不能运行，要等，也许要等很长时间，直到当前运行着的任务释放CPU。与前后系统一样，

不可剥夺型内核的任务级响应时间是不确定的，不知道什么时候最高优先级的任务才能拿到CPU的控制权，完全取决于应用程序什么时候释放CPU。

    总之，不可剥夺型内核允许每个任务运行，直到该任务自愿放弃CPU的控制权。中断可以打入运行着的任务。中断服务完成以后将CPU控制权还给被中断了的任务。任务级响应时间要大大好于前后系统，但仍是不可知的，商业软件几乎没有不可剥夺型内核。

2.10    可剥夺型内核
    当系统响应时间很重要时，要使用可剥夺型内核。因此，μC/OS-Ⅱ以及绝大多数商业上销售的实时内核都是可剥夺型内核。最高优先级的任务一旦就绪，总能得到CPU的控制权。当一个运行着的任务使一个比它优先级高的任务进入了就绪态，当前任务的CPU使用权就被剥夺了，或者说被挂起了，那个高优先级的任务立刻得到了CPU的控制权。如果是中断服务子程序使一个高优先级的任务进入就绪态，中断完成时，中断了的任务被挂起，优先级高的那个任务开始运行。如图2.5所示。

图2.5可剥夺型内核

使用可剥夺型内核，最高优先级的任务什么时候可以执行，可以得到CPU的控制权是可知的。使用可剥夺型内核使得任务级响应时间得以最优化。

    使用可剥夺型内核时，应用程序不应直接使用不可重入型函数。调用不可重入型函数时，要满足互斥条件，这一点可以用互斥型信号量来实现。如果调用不可重入型函数时，低优先级的任务CPU的使用权被高优先级任务剥夺，不可重入型函数中的数据有可能被破坏。综上所述，可剥夺型内核总是让就绪态的高优先级的任务先运行，中断服务程序可以抢占CPU，到中断服务完成时，内核让此时优先级最高的任务运行（不一定是那个被中断了的任务）。任务级系统响应时间得到了最优化，且是可知的。μC/OS-Ⅱ属于可剥夺型内核。

2.11    可重入性（Reentrancy）
       可重入型函数可以被一个以上的任务调用，而不必担心数据的破坏。可重入型函数任何时候都可以被中断，一段时间以后又可以运行，而相应数据不会丢失。可重入型函数或者只使用局部变量，即变量保存在CPU寄存器中或堆栈中。如果使用全局变量，则要对全局变量予以保护。程序2.1是一个可重入型函数的例子。

 

 

程序清单2.1可重入型函数
 
void strcpy(char *dest, char *src)
 
{
 
    while (*dest++ = *src++) {
 
        ;
 
    }
 
    *dest = NUL;
 
}
 

 

 

    函数Strcpy()做字符串复制。因为参数是存在堆栈中的，故函数Strcpy()可以被多个任务调用，而不必担心各任务调用函数期间会互相破坏对方的指针。

    不可重入型函数的例子如程序2.2所示。Swap()是一个简单函数，它使函数的两个形式变量的值互换。为便于讨论，假定使用的是可剥夺型内核，中断是开着的，Temp定义为整数全程变量。

 

 程序清单 2.2    不可重入型函数
 
int Temp;
 
 
 
void swap(int *x, int *y)
 
{
 
    Temp = *x;
 
    *x   = *y;
 
    *y   = Temp;
 
}
 

 

       程序员打算让Swap() 函数可以为任何任务所调用，如果一个低优先级的任务正在执行Swap()函数，而此时中断发生了，于是可能发生的事情如图2.6所示。[F2.6(1)]表示中断发生时Temp已被赋值1，中断服务子程序使更优先级的任务就绪，当中断完成时[F2.6(2)]，内核（假定使用的是μC/OS-Ⅱ）使高优先级的那个任务得以运行[F2.6(3)],高优先级的任务调用Swap()函数是Temp赋值为3。这对该任务本身来说，实现两个变量的交换是没有问题的，交换后Z的值是4，X的值是3。然后高优先级的任务通过调用内核服务函数中的延迟一个时钟节拍[F2.6(4)],释放了CPU的使用权，低优先级任务得以继续运行[F2.6(5)].注意，此时Temp的值仍为3！在低优先级任务接着运行时，Y的值被错误地赋为3，而不是正确值1。

图2.6不可重入性函数

    请注意，这只是一个简单的例子，如何能使代码具有可重入性一看就明白。然而有些情况下，问题并非那么易解。应用程序中的不可重入函数引起的错误很可能在测试时发现不了，直到产品到了现场问题才出现。如果在多任务上您还是把新手，使用不可重入型函数时，千万要当心。

    使用以下技术之一即可使Swap()函数具有可重入性：

 

l          把Temp定义为局部变量

l          调用Swap()函数之前关中断，调动后再开中断

l          用信号量禁止该函数在使用过程中被再次调用

 

如果中断发生在Swap()函数调用之前或调用之后，两个任务中的X，Y值都会是正确的。

2.12    时间片轮番调度法
       当两个或两个以上任务有同样优先级，内核允许一个任务运行事先确定的一段时间，叫做时间额度（quantum），然后切换给另一个任务。也叫做时间片调度。内核在满足以下条件时，把CPU控制权交给下一个任务就绪态的任务：

l          当前任务已无事可做

l          当前任务在时间片还没结束时已经完成了。

       目前，μC/OS-Ⅱ不支持时间片轮番调度法。应用程序中各任务的优先级必须互不相同。

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

2.14    2.14静态优先级
    应用程序执行过程中诸任务优先级不变，则称之为静态优先级。在静态优先级系统中，诸任务以及它们的时间约束在程序编译时是已知的。

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

2.16    优先级反转
    使用实时内核,优先级反转问题是实时系统中出现得最多的问题。图2.7解释优先级反转是如何出现的。如图，任务1优先级高于任务2，任务2优先级高于任务3。任务1和任务2处于挂起状态，等待某一事件的发生，任务3正在运行如[图2.7(1)]。此时，任务3要使用其共享资源。使用共享资源之前，首先必须得到该资源的信号量(Semaphore)(见2. 18.04信号量)。任务3得到了该信号量，并开始使用该共享资源[图2.7（2）]。由于任务1优先级高，它等待的事件到来之后剥夺了任务3的CPU使用权[图2.7(3)]，任务1开始运行[图2.7(4)]。运行过程中任务1也要使用那个任务3正在使用着的资源，由于该资源的信号量还被任务3占用着，任务1只能进入挂起状态，等待任务3释放该信号量[图2.7(5)]。任务3得以继续运行[图2.7(6)]。由于任务2的优先级高于任务3，当任务2等待的事件发生后，任务2剥夺了任务3的CPU的使用权[图2.7(7)]并开始运行。处理它该处理的事件[图2.7(8)]，直到处理完之后将CPU控制权还给任3[图2.7(9)]。任务3接着运行[图2.7(10)]，直到释放那个共享资源的信号量[图27(11)]。直到此时,由于实时内核知道有个高优先级的任务在等待这个信号量，内核做任务切换，使任务1得到该信号量并接着运行[图2.7(12)]。

    在这种情况下,任务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-Ⅱ不支持优先级继承,一些商业内核有优先级继承功能。

图2.7优先级反转问题

    图2.8解释如果内核支持优先级继承的话,在上述例子中会是怎样一个过程。任务3在运行[图2.8(1)],任务3申请信号量以获得共享资源使用权[图2.8(2)],任务3得到并开始使用共享资源[图2.8(3)]。后来CPU使用权被任务1剥夺[图2.8(4)],任务1开始运行[图2.8(5)],任务1申请共享资源信号量[图2.8(6)]。此时,内核知道该信号量被任务3占用了,而任务3的优先级比任务1低,内核于是将任务3的优先级升至与任务1一样,,然而回到任务3继续运行,使用该共享资源[图2.7(7)],直到任务3释放共享资源信号量[图2。8(8)]。这时,内核恢复任务3本来的优先级并把信号量交给任务1,任务1得以顺利运行。 [图2.8(9)],任务1完成以后[图2.8(10)]那些任务优先级在任务1与任务3之间的任务例如任务2才能得到CPU使用权,并开始运行 [图2.8(11)]。注意,任务2在从[图2.8(3)]到[图2.8(10)]的任何一刻都有可能进入就绪态,并不影响任务1、任务3的完成过程。在某种程度上,任务2和任务3之间也还是有不可避免的优先级反转。

图2.8

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

一项有意思的技术可称之为单调执行率调度法RMS(Rate Monotonic Scheduling),用于分配任务优先级。这种方法基于哪个任务执行的次数最频繁,执行最频繁的任务优先级最高。见图2.9。

 

图2.9 基于任务执行频繁度的优先级分配法

 

任务执行频繁度（Hz）

RMS做了一系列假设：

l          所有任务都是周期性的

l          任务间不需要同步，没有共享资源,没有任务间数据交换等问题

l          CPU必须总是执行那个优先级最高且处于就绪态的任务。换句话说，要使用可剥夺型调度法。

给出一系列n值表示系统中的不同任务数，要使所有的任务满足硬实时条件，必须使不等式[2.1]成立，这就是RMS定理：

[2.1]

 

        这里Ei是任务i最长执行时间，Ti是任务i的执行周期。换句话说，Ei/Ti是任务i所需的CPU时间。表2.1给出n(21/n - 1 )的值，n是系统中的任务数。对于无穷多个任务，极限值是  或0.693。这就意味着，基于RMS，要任务都满足硬实时条件，所有有时间条件要求的任务i总的CPU利用时间应小于70%！请注意，这是指有时间条件要求的任务，系统中当然还可以有对时间没有什么要求的任务，使得CPU的利用率达到100%。使CPU利用率达到100%并不好，因为那样的话程序就没有了修改的余地，也没法增加新功能了。作为系统设计的一条原则，CPU利用率应小于60%到70%。

        RMS认为最高执行率的任务具有最高的优先级，但最某些情况下，最高执行率的任务并非是最重要的任务。如果实际应用都真的像RMS说的那样，也就没有什么优先级分配可讨论了。然而讨论优先级分配问题，RMS无疑是一个有意思的起点。

 

 

表2.1基于任务到CPU最高允许使用率.

 
 
任务数
 n(21/n - 1)
 
   1
 1.000
 
   2
 0.828
 
   3
 0.779
 
   4
 0.756
 
   5
 0.743
 
   .
 .
 
   .
 .
 
   .
 .
 
   ∞
 0.693
 

 

2.18    互斥条件
    实现任务间通讯最简便到办法是使用共享数据结构。特别是当所有到任务都在一个单一地址空间下，能使用全程变量、指针、缓冲区、链表、循环缓冲区等，使用共享数据结构通讯就更为容易。虽然共享数据区法简化了任务间的信息交换，但是必须保证每个任务在处理共享数据时的排它性，以避免竞争和数据的破坏。与共享资源打交道时，使之满足互斥条件最一般的方法有：

l          关中断

l          使用测试并置位指令

l          禁止做任务切换

l          利用信号量

2.18.1  关中断和开中断
    处理共享数据时保证互斥，最简便快捷的办法是关中断和开中断。如示意性代码程序2.3所示：

 

程序清单2.3    关中断和开中断
 
Disable interrupts;                                           /*关中断*/
 
Access the resource (read/write from/to variables);     /*读/写变量*/
 
Reenable interrupts;                                         /*重新允许中断*/

 
 

 

   μC/OS-Ⅱ在处理内部变量和数据结构时就是使用的这种手段，即使不是全部，也是绝大部分。实际上μC/OS-Ⅱ提供两个宏调用，允许用户在应用程序的C代码中关中断然后再开中断：OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()[参见8.03.02 OS_ENTER_CRITICAL()和OS_EXIT_CRITICALL()],这两个宏调用的使用法见程序2.4

 

程序清单2.4利用μC/OS_Ⅱ 宏调用关中断和开中断
 
void Function (void)
 
{
 
    OS_ENTER_CRITICAL();
 
    .
 
    .    /*在这里处理共享数据*/
 
    .
 
    OS_EXIT_CRITICAL();
 
}
 

 

 

    可是，必须十分小心，关中断的时间不能太长。因为它影响整个系统的中断响应时间，即中断延迟时间。当改变或复制某几个变量的值时，应想到用这种方法来做。这也是在中断服务子程序中处理共享变量或共享数据结构的唯一方法。在任何情况下，关中断的时间都要尽量短。

    如果使用某种实时内核，一般地说，关中断的最长时间不超过内核本身的关中断时间，就不会影响系统中断延迟。当然得知道内核里中断关了多久。凡好的实时内核，厂商都提供这方面的数据。总而言之，要想出售实时内核，时间特性最重要。

2.18.2  测试并置位
    如果不使用实时内核，当两个任务共享一个资源时，一定要约定好，先测试某一全程变量，如果该变量是0，允许该任务与共享资源打交道。为防止另一任务也要使用该资源，前者只要简单地将全程变量置为1，这通常称作测试并置位(Test-And-Set),或称作TAS。TAS操作可能是微处理器的单独一条不会被中断的指令，或者是在程序中关中断做TAS操作再开中断，如程序清单2.5所示。

 

程序清单2.5 利用测试并置位处理共享资源
 
Disable interrupts;                              关中断
 
if (‘Access Variable’ is 0) {                  如果资源不可用，标志为0
 
    Set variable to 1;                           置资源不可用，标志为1
 
    Reenable interrupts;                         重开中断
 
    Access the resource;                         处理该资源
 
    Disable interrupts;                          关中断
 
    Set the ‘Access Variable’ back to 0;      清资源不可使用，标志为0
 
    Reenable interrupts;                         重新开中断
 
} else {                                            否则
 
    Reenable interrupts;                          开中断
 
/* You don’t have access to the resource, try back later; */

/* 资源不可使用，以后再试; */
 
}
 

 

    有的微处理器有硬件的TAS指令(如Motorola 68000系列,就有这条指令)

2.18.3  禁止,然后允许任务切换
    如果任务不与中断服务子程序共享变量或数据结构,可以使用禁止、然后允许任务切换。(参见3.06给任务切换上锁和开锁)。如程序清单2.6所示，以μC/OS-Ⅱ的使用为例，两个或两个以上的任务可以共享数据而不发生竞争。注意，此时虽然任务切换是禁止了，但中断还是开着的。如果这时中断来了，中断服务子程序会在这一临界区内立即执行。中断服务子程序结束时，尽管有优先级高的任务已经进入就绪态，内核还是返回到原来被中断了的任务。直到执行完给任务切换开锁函数OSSchedUnlock (),内核再看有没有优先级更高的任务被中断服务子程序激活而进入就绪态，如果有，则做任务切换。虽然这种方法是可行的，但应该尽量避免禁止任务切换之类操作，因为内核最主要的功能就是做任务的调度与协调。禁止任务切换显然与内核的初衷相违。应该使用下述方法。

 

程序清单2.6  用给任务切换上锁，然后开锁的方法实现数据共享.
 
void Function (void)
 
{
 
    OSSchedLock();
 
    .
 
    .    /* You can access shared data in here (interrupts are recognized) */
 
.    /*在这里处理共享数据(中断是开着的)*/
 
    OSSchedUnlock();
 
}
 

 

2.18.4  信号量(Semaphores)
    信号量是60年代中期Edgser Dijkstra 发明的。信号量实际上是一种约定机制，在多任务内核中普遍使用.信号量用于：

l          控制共享资源的使用权(满足互斥条件)

l          标志某事件的发生

l          使两个任务的行为同步

(译者注：信号与信号量在英文中都叫做Semaphore，并不加以区分，而说它有两种类型，二进制型(binary)和计数器型(counting)。本书中的二进制型信号量实际上是只取两个值0和1的信号量。实际上 这个信号量只有一位，这种信号量翻译为信号更为贴切。而二进制信号量通常指若干位的组合。而本书中解释为事件标志的置位与清除(

见2.21))。

    信号像是一把钥匙，任务要运行下去，得先拿到这把钥匙。如果信号已被别的任务占用，该任务只得被挂起，直到信号被当前使用者释放。换句话说，申请信号的任务是在说：“把钥匙给我，如果谁正在用着，我只好等！”信号是只有两个值的变量，信号量是计数式的。只取两个值的信号是只有两个值0和1的量，因此也称之为信号量。计数式信号量的值可以是0到255或0到65535，或0到4294967295，取决于信号量规约机制使用的是8位、16位还是32位。到底是几位，实际上是取决于用的哪种内核。根据信号量的值，内核跟踪那些等待信号量的任务。

    一般地说，对信号量只能实施三种操作：初始化(INITIALIZE)，也可称作建立(CREATE)；等信号(WAIT)也可称作挂起(PEND)；给信号(SIGNAL)或发信号(POST)。信号量初始化时要给信号量赋初值，等待信号量的任务表(Waiting list)应清为空。

    想要得到信号量的任务执行等待(WAIT)操作。如果该信号量有效(即信号量值大于0)，则信号量值减1，任务得以继续运行。如果信号量的值为0，等待信号量的任务就被列入等待信号量任务表。多数内核允许用户定义等待超时，如果等待时间超过了某一设定值时，该信号量还是无效，则等待信号量的任务进入就绪态准备运行，并返回出错代码(指出发生了等待超时错误)。

    任务以发信号操作(SIGNAL)释放信号量。如果没有任务在等待信号量，信号量的值仅仅是简单地加1。如果有任务在等待该信号量，那么就会有一个任务进入就绪态，信号量的值也就不加1。于是钥匙给了等待信号量的诸任务中的一个任务。至于给了那个任务，要看内核是如何调度的。收到信号量的任务可能是以下两者之一。

l          等待信号量任务中优先级最高的，或者是

l          最早开始等待信号量的那个任务，即按先进先出的原则(First In First Out ，FIFO)

有的内核有选择项，允许用户在信号量初始化时选定上述两种方法中的一种。但μC/OS-Ⅱ只支持优先级法。如果进入就绪态的任务比当前运行的任务优先级高(假设，是当前任务释放的信号量激活了比自己优先级高的任务)。则内核做任务切换(假设，使用的是可剥夺型内核)，高优先级的任务开始运行。当前任务被挂起。直到又变成就绪态中优先级最高任务。

    程序清单2.7示意在μC/OS-Ⅱ中如何用信号量处理共享数据。要与同一共享数据打交道的任务调用等待信号量函数OSSemPend()。处理完共享数据以后再调用释放信号量函数OSSemPost()。这两个函数将在以后的章节中描述。要注意的是，在使用信号量之前，一定要对该信号量做初始化。作为互斥条件，信号量初始化为1。使用信号量处理共享数据不增加中断延迟时间，如果中断服务程序或当前任务激活了一个高优先级的任务，高优先级的任务立即开始执行。

 

程序清单2.7   通过获得信号量处理共享数据
 
OS_EVENT *SharedDataSem;
 
void Function (void)
 
{
 
    INT8U err;
 
    OSSemPend(SharedDataSem, 0, &err);
 
    .
 
    .    /* You can access shared data in here (interrupts are recognized) */
 
    .    /*共享数据的处理在此进行，(中断是开着的)*/
 
    OSSemPost(SharedDataSem);
 
}
 

 

当诸任务共享输入输出设备时，信号量特别有用。可以想象，如果允许两个任务同时给打印机送数据时会出现什么现象。打印机会打出相互交叉的两个任务的数据。例如任务1要打印“I am Task!”，而任务2要打印“I am Task2!”可能打印出来的结果是：“I Ia amm T Tasask k1!2!”

    在这种情况下，使用信号量并给信号量赋初值1(用二进制信号量)。规则很简单，要想使用打印机的任务，先要得到该资源的信号量。图2.10两个任务竞争得到排它性打印机使用权，图中信号量用一把钥匙表示，想使用打印机先要得到这把钥匙。

图2.10用获取信号量来得到打印机使用权

 

    上例中，每个任务都知道有个信号表示资源可不可以使用。要想使用该资源，要先得到这个信号。然而有些情况下，最好把信号量藏起来，各个任务在同某一资源打交道时，并不知道实际上是在申请得到一个信号量。例如，多任务共享一个RS-232C外设接口，各任务要送命令给接口另一端的设备并接收该设备的回应。如图2.11所示。

    调用向串行口发送命令的函数CommSendCmd()，该函数有三个形式参数：Cmd指向送出的ASCII码字符串命令。Response指向外设回应的字符串。timeout指设定的时间间隔。如果超过这段时间外设还不响应，则返回超时错误信息。函数的示意代码如程序清单2.8所示。

 

程序清单 2.8   隐含的信号量。
 
INT8U CommSendCmd(char *cmd, char *response, INT16U timeout)
 
{
 
    Acquire port's semaphore;
 
    Send command to device;
 
    Wait for response (with timeout);
 
    if (timed out) {
 
        Release semaphore;
 
        return (error code);
 
    } else {
 
        Release semaphore;
 
        return (no error);
 
    }
 
}
 

 

    要向外设发送命令的任务得调用上述函数。设信号量初值为1，表示允许使用。初始化是在通讯口驱动程序的初始化部分完成的。第一个调用CommSendCmd()函数的任务申请并得到了信号量，开始向外设发送命令并等待响应。而另一个任务也要送命令，此时外设正“忙”，则第二个任务被挂起，直到该信号量重新被释放。第二个任务看起来同调用了一个普通函数一样，只不过这个函数在没有完成其相应功能时不返回。当第一个任务释放了那个信号量，第二个任务得到了该信号量，第二个任务才能使用RS-232口。

图2.11在任务级看不到隐含的信号量

    计数式信号量用于某资源可以同时为几个任务所用。例如，用信号量管理缓冲区阵列(buffer pool)，如图2.12所示。缓冲区阵列中共有10个缓冲区，任务通过调用申请缓冲区函数BufReq()向缓冲区管理方申请得到缓冲区使用权。当缓冲区使用权还不再需要时，通过调用释放缓冲区函数BufRel()将缓冲区还给管方。函数示意码如程序清单2.9所示

 

 

程序清单 2.9   用信号量管理缓冲区。
 
BUF *BufReq(void)
 
{
 
   BUF *ptr;
 
 
 
   Acquire a semaphore;
 
   Disable interrupts;
 
   ptr         = BufFreeList;
 
   BufFreeList = ptr->BufNext;
 
   Enable interrupts;
 
   return (ptr);
 
}
 
 
 
 
 
void BufRel(BUF *ptr)
 
{
 
   Disable interrupts;
 
   ptr->BufNext = BufFreeList;
 
   BufFreeList  = ptr;
 
   Enable interrupts;
 
   Release semaphore;
 
}
 

图2.12 计数式信号量的用法

缓冲区阵列管理方满足前十个申请缓冲区的任务，就好像有10把钥匙可以发给诸任务。当所有的钥匙都用完了，申请缓冲区的任务被挂起，直到信号量重新变为有效。缓冲区管理程序在处理链表指针时，为满足互斥条件，中断是关掉的(这一操作非常快)。任务使用完某一缓冲区，通过调用缓冲区释放函数BufRel()将缓冲区还给系统。系统先将该缓冲区指针插入到空闲缓冲区链表中(Linked list)然后再给信号量加1或释放该信号量。这一过程隐含在缓冲区管理程序BufReq()和BufRel()之中，调用这两个函数的任务不用管函数内部的详细过程。