UCOSii（四）——任务的通信与同步

一、任务的通信方式

1.1 共享内存

进程间的通信方式有两种，一种是使用共享内存，这种方式基本不依赖OS，也没有相应的系统开销。另一种则需要OS支持，通过建立链接器实现任务间的通信。

Message Passing Share Memory

依赖内核，需要预先建立Link，内核负担开销 无需预先建立Link，用户进程负责开销

只有建立链接的双方才可以通信 所有进程都可以访问

需提供Link Creation、Link Capacity、 Message Lost等机制 需要提供互斥存取

两种通信方式的区别

在UCOSii中，多个任务使用同一块内存区域需要提供一种互斥存取的方法。否则该段共享数据很有可能在被访问前就被其他任务重置了。

利用关中断宏OS_ENTER_CRITICAL()、OS_EXIT_CRITICAL()以及开调度锁是利用函数 OSSchedLock()、 OSSchekUnlock()可以实现单任务对某一资源的暂时性独享。

用这种方法实现数据共享存在很大的局限性，一个简单的例子，当一个共享资源允许被多个任务同时占用，这种方式就很低效。

RTOS会提供信号量、邮箱和消息队列来支持任务间的通信与同步，即使是非实时性操作系统也同样有这样的接口，这已经类似于一种规范。

1.2 信号量

信号量的概念最初由Edsger Dijkstra提出。

假定有多个任务需要读写一块板卡上的flash芯片，如果他们之间没有协商，而是各自单独对flash进行读写，就会使flash的读写操作处于不可预料的状态中。此时可以建立一个信号量，当有任务进行读写操作时，便申请该信号量，操作完成后再释放。如果已经有任务占用了该信号量，请求信号量就会失败，任务可以等待该信号量被释放，再进行相关的操作。一个共享资源也可能最多被几个任务占用，这种情况下信号量可以为一个计数器，当有任务占用共享资源时，信号量减一。

1.3 邮箱

很明显，信号量只解决了共享资源的占用的问题。它不能传递信息，假如某下位机有一个专门用来解释上位机控制命令的任务，当上位机没有数据传送过来时，该任务处于挂起状态。但当通讯中断发生后，该任务不仅要知道已经有控制字被传送过来，还需要知道该控制字是什么。所以信号量在这里并不适用，解决的办法是建立一个邮箱。由于要传递的信息很可能超过一个常规变量的大小，所以邮箱的内容是一个指针。将命令解释器的优先级设置为高于其他任务，它始终调等待一个邮箱。将该邮箱里指针的值指向接收缓冲区，该任务就开始处理控制字。

1.4 消息队列

消息队列是一组指针，它可以被看成是一组邮箱的集合。

假设有一个流水线分拣系统，传感器会检测货物的一些物理参数。每来一个产品，系统就建立一个关于该产品的结构体用于描述该产品的属性。如果使用邮箱，那么在一个产品被分拣任务处理前，新到产品就必须延时处理。使用消息队列，可以将一组指针推入队列，每一个指针都描述一个产品。这样分拣任务可以根据先后入队列的顺序，依次分拣每个产品。

二、事件控制块

2.1 Ecb的结构

事件控制块Ecb用来维护一个事件控制块的所有信息，该结构体不仅包含信号量/邮箱/消息队列的值，还包含等待它的任务列表。

Ecb反映了一种朴素的简化程序逻辑结构的思想。用统一的数据结构来描述对象的属性，再在处理程序里统一处理。对信号量/邮箱/消息队列的创建、维护都只是读写Ecb，在调度程序里，统一处理Ecb。

Ecb原型

typedef struct {

void *OSEventPtr; /* 指向消息或者消息队列的指针 */

INT8U OSEventTbl[OS_EVENT_TBL_SIZE]; /* 等待任务列表 */

INT16U OSEventCnt; /* 计数器(当事件是信号量时) */

INT8U OSEventType; /* 事件类型 */

INT8U OSEventGrp; /* 等待任务所在的组 */

} OS_EVENT;

OSEventType表示事件类型，信号量/邮箱/消息队列。

如果事件是信号量，OSEventCnt表示信号量的值。

如果事件是邮箱或者消息队列，OSEventPtr表示指向消息或者消息队列的指针。

OSEventTbl和OSEventGrp用来表示等待该事件的任务组。

2.2 Ecb通用操作

为了减少代码量，UCOSii将一些与Event有关的，会被重用的操作写成了独立的函数。

初始化Ecb

当Ecb被建立时，需要对其进行清0，防止该段Ram里已经被写入了值。

使一个任务就绪态

使用OSSemPost(),OSMboxPost(),OSQPost(),和 OSQPostFront()发送一个事件后，事件等待列表中优先级最高的任务要被置于就绪状态，这时调用OSEventTaskRdy()函数。

该函数被用来使等待事件发生的最高优先级任务得到该事件后，使他进入就绪状态。

因为Ucosii强制所有任务不同优先级，所以可以通过任务优先级取得Tcb的指针。然后该函数将OSTCBDly和OSTCBEventPtr结束任务延时，标志事件结束，再将事件的相应参数（信号量的指，消息和队列指针的值）传递给Tcb。最后，该函数还要判断该任务是否因为调用OSTaskSuspend()而被挂机。如果没有，则进入就绪队列。

OSTaskSuspend()是一个额外的机制，凡是调用OSTaskSuspend()被挂机的任务，只能调用OSTaskResume()来进行恢复。

使一个任务等待某事件

当使用OSSemPend(),OSMboxPend()或者 OSQPend()函数让某个任务等待某事件时，要调用OSEventTaskWait()函数。

该函数将任务从就绪列表中删除，再加入Ecb中的等待列表。

使一个任务因等待时间超时而进入就绪状态

当使用SSemPend(),OSMboxPend()或者 OSQPend()让任务等待某个事件，而等待事件超时后，将调用OSTimeTick()函数。

该函数清除Ecb等待列表里的任务，被将Tcb里标记事件的指针清0。

三、相关函数

3.1 信号量

信号量的建立，OSSemCreate()

初始化一个信号量要从划给Ecb的内存里申请一块空闲区域，然后初始化一个Ecb，并将Ecb里的事件类型标记为信号量。

这个函数会返回一个指向Ecb块的指针，之后对信号量的操作都要通过这个指针来实现。

等待一个信号量，OSSemPend()

OSSemPend()先判断事件的类型，如果是信号量且值不为0。就把信号量的值减一，函数返回请求成功的标志。

在信号量被占用时，任务将被挂起。只有当等待超时，或者得到该信号量时，任务才被唤醒。

发送一个信号量，OSSemPost()

OSSemPost()同样先判断参数里的指针是否指向一个信号量的Ecb。

如果有任务正在等待该信号量，那么把等待列表里优先级最高的任务移除，让它就绪。

否则就把信号量加1。

无等待地请求一个信号量，OSSemAccept()

OSSemAccept()用来在中断程序中请求信号量，其实它只是取得当前信号量的值。

如果当前信号量的值不为0，那么OSSemAccept()会在取得该值后，将计数器减1。

查询信号量状态，OSSemQuery()

OSSemQuery()返回就绪列表和信号量的值，在查询之前要先建立一个接收返回值的结构体。因为无需包含Ecb中的类型和消息指针，所以该结构体类型和Ecb是不同的。

3.2 邮箱

创建一个邮箱，OSMboxCreate()

和OSSemCreate()的区别是，Ecb的类型为邮箱，并且邮箱的初始值会被写成参数传递来的值。

等待一个邮箱中的消息,OSMboxPend()

和OSSemPend()的区别是，OSMboxPend()判断该指针是否是NULL，不是就取得该指针，否则就挂起开始等待该邮箱。

发送一个消息到邮箱中,OSMboxPost()

和Sem的Post函数区别是，如果邮箱已经有非空指针存在里面，函数会返回邮箱满了的错误。

无等待地从邮箱中得到一个消息, OSMboxAccept()

清空邮箱，并且返回邮箱里的指针。

查询一个邮箱的状态, OSMboxQuery()

返回Ecb的部分内容，不包含类型和信号量计数器。

3.3 消息队列

UCOSii里针对消息队列的函数有7个。分别是OSQCreate(),OSQPend(),OSQPost(),OSQPostFront(),OSQAccept(),OSQFlush()和 OSQQuery()函数

其中大部分和信号量/邮箱的函数在思想上是一致的。因为消息队列是一个循环队列的结构，因此在推送消息的时候，存在先进先出和后进先出的问题。即新消息到来时，到底是插入在队列的尾部，还是插入在队列的前部。OSQPost(),OSQPostFront()分别对应两种不同的入栈方式。

OSQFlush()用来清空队列。

为了支持消息队列的特性，要在使用消息队列时，预先定义队列的最大值。而且为了支持队列特性，在Ecb里的指针实际指向的是一个队列控制块，相关的算法就不列举了。