在ucOS- II中规划了五种通讯机制，或许说是同步机制，分别是信号量（semaphore），互斥体（mutual exclusion semaphore），事情组（event flag），邮箱（message box）和行列（queue），而事情（event）则是这几种通讯机制的中心，这几天学习了一下这几种机制，总结一下先，呵呵。
1. 先总结一下作为中心的事情操控机制：
1.1 数据结构规划：
1.2 事情操控的中心函数有四个，根本上便是对等候使命表的操作，这些函数将作为上述五种通讯机制的中心功用：
1.2.1
1.2.2 OS_EventTaskRdy：首要找到等候该事情的优先级最高的使命，将其从等候使命表中移走，然后更新该使命的TCB，最高依据TCB的OSTCBStat变量更新使命安排妥当表（假如该使命没有等候任何事情，那么就把它参加使命安排妥当表）。
1.2.3 OS_EventTaskWait：首要把当时使命从使命安排妥当表中移走，然后把当时使命加进这个事情的等候使命表。这个函数其实便是挂起当时使命！
1.2.4 OS_EventTO：超时处理函数，将当时使命从等候使命列表中移走，并更新TCB使其进入安排妥当状况，值得留意的是，它并不更新安排妥当使命表！！！
2. 信号量的完成
信号量的用处首要有三个：榜首， 标明一个或多个事情的产生； 第二， 标明共享资源的可用（二值信号量）； 第三， 标明n个相同资源的拜访（多值信号量）（这是书上的说法，我以为应该表述为： 标明共享资源对n个使命的可用）。
2.1 数据结构规划：信号量仅仅用到ECB，一个信号量用一个ECB标明，没有用到其他数据结构。其间ECB的OSEventPtr变量没有用到，仅仅简略的将其设为0，因而信号量是比较简略的一个通讯机制。
2.2 中心函数首要有四个：
2.2.1 OSSemCreate：创立一个信号量：首要从事情操控块缓冲区中得到一个ECB，然后初始化这个ECB，对其间等候使命表的初始化用到OS_EventWaitListInit。
2.2.2 OSSemDel：毁掉一个信号量：有两种状况， 榜首，只需在没有使命等候该信号量的时分才删去；第二，不论有没有使命等候该信号量都强制删去；关于榜首种状况，用OS_DEL_NO_PEND进行标 识，这个时分，假如的确没有使命在等候该信号量，将ECB归还到ECB缓冲区，然后回来； 假如有使命在等候该信号量，直接回来过错标识，以告知调用者删去失利。 关于第二种状况，用OS_DEL_ALWAYS进行标识，首要用OS_EventTaskRdy将等候使命表中的一切使命都移走，然后将该ECB归还到 ECB缓冲区。这个时分要做判别假如刚刚有使命在等候该信号量（这个判别在移走之前现已做好），就必须从头调度：OS_Sched！所以，假如当时使命不是优先级最高的使命，那么这个函数将会被挂起，呵呵。
2.2.3 OSSemPend：该函数或许会引起当时使命被挂起：首要判别该信号量是否可用，也便是ECB的OSEventCnt是否不为0，假如可用的话更新 ECB然后回来，使命持续履行；假如不可用，那么就更新当时使命的TCB，然后用OS_EventTaskWait挂起使命，然后从头调度。这时，该函数 将或许被挂起，直到当时使命获得该信号量然后康复履行。然后该函数判别当时使命持续履行的原因，假如是超时的话，调用OS_EventTO，假如是得到信 号量而回来的话，更新当时TCB，然后回来。别的，这也便是OS_EventTO不更新安排妥当表的原因——自身现已在运转了呀，呵呵。
2.2.4 OSSemPost：该函数开释该信号量，然后可以使正在等候该信号量的使命康复履行： 首要判别等候使命表中是否有使命正在等候该信号量，假如有的话就经过OS_EventTaskRdy使等候使命表中优先级最高的使命不再等候该信号量（具 体的操作如上面所述）。接下来（不论有没有使命正在等候该信号量）就更新ECB，其实便是将其间的变量OSEventCnt加1。
前面临信号量 做了一个简略的总结，下面临互斥体，邮箱和行列以及事情组做一个总结，因为事情组没有用到ECB，而其他的都有用到ECB，所以最终总结事情组，也便是 说，除了事情组会从一个作者专门规划的体系缓冲区请求用到的数据结构，其他的都会从ECB缓冲区中请求ECB。
3. 互斥体的完成
从其姓名，mutual exclusion semaphore，可以看出来，其实互斥体归于信号量的一种，其实它是一个二值信号量，之所以把它独自拿出来规划，首要是为了处理使命优先级回转的问题 ——当该互斥体被一个使命占用的时分，假如有更高的优先级使命等候该互斥体，那么将占用该互斥体的使命的优先级提高到预先设定的那个比较高的优先级，然后 能改进优先级回转的问题，可是不能彻底去掉，呵呵。
3.1 数据结构的规划：
和信号量相同，互斥体只用到ECB这一数据结构， 不同的是，因为它首要被规划用来处理优先级回转的问题，每一个互斥体都会一个完成设定的优先级联系起来，这个优先级应该尽量比较高，这样，具有这个互斥体 的使命将会先被处理，然后改进优先级回转的问题。ECB中，OSEventType用来标识该事情对象是个互斥体；OSEventCnt的高8位用来寄存 与该互斥体相关的优先级，而低8位寄存具有该互斥体的使命优先级；OSEventPtr寄存具有该互斥体的使命的TCB指针；剩余的等候使命表和信号量一 样，没任何差异。
3.2 中心函数和信号量相同有四个，可是因为每个互斥体都与一个使命优先级联系起来，完成有一些杂乱：
3.2.1 OSMutexCreate：创立一个互斥体：首要判别该优先级有没有被使命占用，假如有的话，创立失利；然后从ECB缓冲区中取一个ECB； 最终初始化得到的ECB，值得留意的是，ECB的变量OSEventCnt的高8位用来寄存相关的优先级，当然，等候使命表仍是用 OS_EventWaitListInit来初始化。
3.2.2 OSMutexDel： 删去一个互斥体：其完成与信号量根本相同，仅有的不必仍是因为其相关了一个使命优先级，删去的时分应该将优先级从头标识为可用。
3.2.3 OSMutexPend：等候一个互斥体：首要判别是否该互斥体可用，假如可用的的话就用当时使命的优先级和TCB更新ECB，标明该互斥表现已被当时使命占用，直接回来，这种状况最简略； 假如互斥表现已被其他使命占用：首要判别占用该互斥体的使命的优先级是不是比当时使命的优先级低，假如是的话就要做提高占用该互斥体使命优先级的操作，这也便是互斥体的首要用处——更新安排妥当使命表，更新该使命TCB，更新使命优先级标识表OSTCBPrioTbl。剩余的处理与信号量的OSSemPend的处理彻底一致：更 新当时使命的TCB，然后用OS_EventTaskWait挂起使命，然后从头调度。这时，该函数将或许被挂起，直到当时使命获得该互斥体然后康复执 行。然后该函数判别当时使命持续履行的原因，假如是超时的话，调用OS_EventTO，假如是得到该互斥体而回来的话，更新当时TCB，然后回来。
3.2.4 OSMutexPost：开释一个互斥体，留意，只需占用该互斥体的使命可以开释该互斥体！首要查看当时使命是否占用该互斥体，假如不是的话直接回来过错；然后判别当时的使命优先级是否被提高过，假如是的话，就做康复当时使命的优先级——更新安排妥当使命表，更新当时使命TCB，更新使命优先级标识表OSTCBPrioTbl；接下来，经过等候使命表判别是否有使命在等候该互斥体，假如有的话经过OS_EventTaskRdy其间优先级最高的使命，然后将该互斥体标识为这个优先级最高的使命所占用， 假如没有使命在等候该互斥体，就重置它。
4. 邮箱的完成
邮箱（mail box）首要用来从一个使命向别的一个使命发送一个音讯，其实便是一个指针，因而，与信号量和互斥提稍有不同，信号量和互斥体用来同步对资源的拜访，而这 个资源在信号量和互斥体中是没有表现的，换句话说，从信号量和互斥体的ECB中不能看出是在同步哪些资源，而邮箱的话，这个资源（也便是音讯）被放在 ECB中！总的说来，邮箱的完成相对来说很简略！
4.1 数据组织的规划：
邮箱也只用到ECB，和信号量以及互斥体不同的是，邮箱没有用到OSEventCnt，而是运用OSEventPtr来寄存音讯（指针）。其他的和信号量于互斥体相同。
4.2 中心函数也是四个，与信号量和互斥体相同：
4.2.1 OSMboxCreate：创立一个邮箱：完成很简略，首要请求一个ECB，然后初始化这个ECB，其间用OS_EventWaitListInit初始化等候使命表。
4.2.2 OSMboxDel：删去一个邮箱：与信号量中OSSemDel彻底相同。
4.2.3 OSMboxPend：等候一个邮箱音讯：首要查看该邮箱中是否有音讯，假如有的话取出音讯，然后回来； 假如邮箱中没有音讯，那么更新当时使命TCB，并用OS_EventTaskWait挂起当时使命，然后从头调度：OS_Sched! 这个时分当时使命将会被挂起，直到等候的音讯降临或许超时才满意康复履行，之后，它查看邮箱中是否有音讯，假如有的话，取走音讯，正常回来；假如邮箱中仍 然没有音讯，那么当时使命康复履行是因为超时，所以回来超时过错！
声明：本文内容来自网络转载或用户投稿，文章版权归原作者和原出处所有。文中观点，不代表本站立场。若有侵权请联系本站删除（kf@86ic.com）https://www.86ic.net/yingyong/iot/257597.html
