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里的指针实际指向的是一个队列控制块,相关的算法就不列举了。