4.任务的同步及通信.ppt

* 查询消息队列的参数pdata是OS_Q_DATA类型的指针，结构如下： typedef struct { void *OSMsg; INT16U OSNMsgs; INT16U OSQSize; INT8U OSEventTbl[OS_EVENT_TBL_SIZE]; INT8U OSEventGrp; } OS_Q_DATA; * * * * * * * 初始化后的事件控制块： OSEventType OSEventCnt OSEventPtr OSEventGrp = 0x00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 任务等待表 OSEventTbl[] OS_EVENT pevent * * * 在uC/OS-II初始化时，系统会在初始化函数OSInit()中按应用程序使用事件的总数OS_MAX_EVENTS(在文件OS_CFG.H中定义），创建OS_MAX_EVENTS个空事件控制块并借用成员OSEventPtr作为链接指针，把这些空事件控制块链接成一个如图5-7所示的单向链表。由于链表中的所有控制块尚未与具体事件相关联，因此该链表叫做空事件控制块链表。以后，每当应用程序创建一个事件时，系统就会从链表中取出一个空事件控制块，并对它进行初始化以描述该事件。而当应用程序删除一个事件时，就会将该事件的控制块归还给空事件控制块链表。 * 图5-8是一个计数器当前值为3，且有4个等待任务的信号量的示意图。等待信号量的任务优先级分别为4、7、10、19。 * OS_EVENT_TYPE_SEM 0x000A NULL 0x00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 * 为防止任务因得不到信号量而处于长期的等待状态，函数OSSemPend()允许用参数timeout设置一个等待时间的限制。当任务等待时间超过timeout时，可以结束等待状态而进入就绪状态，如果参数timeout被设置为0，则表明任务的等待时间为无限长。当任务需要访问一个共享资源时，先要请求管理该资源的信号量，这样就可以根据信号量当前是否有效来决定该任务是否可以继续运行。 如果信号量有效（即信号量的的计数器OSEventCnt的值大于0）则把信号量计数器减1，然后继续运行任务。 如果信号量无效（即信号量的的计数器OSEventCnt的值等于0）则会在等待任务表中把该任务对应的位置1而让任务处于等待状态，并把等待时限timeout保存在任务控制块TCB的成员OSTCBDly中。 * * 从例5-4代码中可以看到，使用事件控制块描述的信号量，无论在使用方面还是在信号量的完善性方面，他的确比简单形式的信号量要方便得多。 * * * 在剥夺型内核中，当任务以独占方式使用共享资源时，会出现低优先级任务先于高优先级任务而被运行的现象，这种现象叫做任务优先级反转。在一般情况下是不允许出现这种任务优先级反转现象的。下面就对优先级的反转现象进行详细分析，以期找出原因及解决方法。 图5-9描述了A、B、C三个任务的运行情况。其中，任务A的优先级别高于任务B，任务B的优先级别高于任务C。任务A和任务C都要使用同一个共享资源S，而用于保护该资源的信号量在同一时间只能允许一个任务以独占的方式对该资源进行访问，即这个信号量是一个互斥型信号量。 现在，假如任务A和任务B都在等待与各自任务相关的事件发生而处于等待状态，而任务C正在运行，且在t1时刻取得了信号量并开始访问共享资源S。 如果在任务C使用共享资源S过程中的t2时刻，任务A等待的事件已经到来，那么由于任务A的优先级别高于任务C的优先级别，所以任务A就剥夺任务C的CPU使用权而进入运行状态，而使任务C中止运行，这样任务C就失去了释放信号量的机会。如果任务A在运行中的t3时刻又要访问共享资源S，但由于任务C还未释放信号量，因此任务A只好等待，以使任务C可以继续使用共享资源S。 以上过程都是正常的，是应用程序设计者意料之中的事情。问题是，如果在任务C继续使用共享资源S过程中的t4时刻，