uCOSII实时操作系统通信机制之内核分析.docxVIP

μC/OS-II通信机制之内核分析 摘要： 本文主要着重对μC/OS-III通信机制的内核分析，研究μC/OS-II内核通信机制的实现方式及实现的技巧，同时分析其中不足之处。 1．引言 μC/OS-II是一种可移植的，可植入ROM的，可裁剪的，抢占式的，实时多任务操作系统内核。它被广泛应用于微处理器、微控制器和数字信号处理器。 uC/OS-II只是一个实时操作系统内核，它仅仅包含了任务调度，任务管理，时间管理，内存管理和任务间的通信和同步等基本功能。没有提供输入输出管理，文件系统，网络等额外的服务。但由于uC/OS-II良好的可扩展性和源码开放，这些非必须的功能完全可以由用户自己根据需要分别实现。 μC/OS-II这款操作系统内核简单易学，通过对其源代码的分析，可以加深我们对操作系统内核的理解，为学习linux等大型操作系统打下基础。 2．操作系统中任务间的通信机制 内核中多个任务之间不可避免的存在相互协同的关系，来完成一定的内核功能。这种协同最直观的就是任务间相互通信。。包括VxWorks 等所有的嵌入式操作系统一般都会提供许多任务间通信的方法，通常包括： （1）共享内存，数据的简单共享。 （2）信号量，基本的互斥和同步。 （3）消息队列和管道，同一CPU 内多任务间消息传递。 （4） Socket 和远程调用，任务间透明的网络通信。 （5）Signals，用于异常处理。 在μC/OS-II中设计了五种通讯机制，或者说是同步机制，分别是信号量（semaphore），互斥体（mutual exclusion semaphore），事件组（event flag），邮箱（message box）和队列（queue）。 3. uC/OS-II中通信机制实现的方式分析 在uC/OS-II中是如何通信机制呢？这几种通信机制有什么关系？或者说有什么共同点有什么不同点？在实现上有哪些步骤是相同的？下面将就这几个问题进行分析论述。 我们知道通信机制是发生在任务之间的，换句话说任务与通信机制存在着关联。在内核又是如何处理这种关联呢？通信机制具体来说是信号量,互斥量，邮箱，队列等。通信机制协调的关系一般是针对两个以上的任务，比如说当两个任务互斥的访问共享资源，就需要一个互斥量，这个互斥量就关联着这两个任务。同样的道理??其他通信机制也是关联着两个以上的任务。那么设计内核时就要考虑如何将他们的关系有效协调地统一管理起来。 在内核中是通过一个事件控制块来实现通信机制与任务的联系。这里所说的事件就是指任务间进行通信时传递信号的统称。这里其实是利用到了一种抽象的思想，即将各种通信机制的共同点抽象出来，于是内核就设计了一个事件控制块的数据结构，这个数据结构是所有通信机制都会用到的，这样的设计就节省了不少代码，因为有共同点意味着有重复代码。 既然知道了事件控制块是实现通信机制代码共享的关键，那么下面我们就来分析下它的数据结构。 typedef struct{INT8U OSEventType; //事件类型INT8U OSEventGrp; //等待任务所在的组INT16U OSEventCnt; //当事件是信号量时的计数器void *OSEventPtr; //指向消息或消息队列的指针INT8U OSEventTbl[OS_EVENT_TBL_SIZE]; //等待任务列表} OS_EVENT; 第一个变量是事件类型，它可以是信号量，互斥型信号量，邮箱或是消息队列中的一种。OSEventPtr是一个泛型指针，只在所定义的事件是邮箱或者消息队列时才会用到，用来指向一个消息，指针类型设计成泛型的，这是一个设计技巧，因为还不知道具体的消息是什么样的数据结构类型。OSEventGrp和OSEventTbl[OS_EVENT_TBL_SIZE]用来控制等待某事件的任务，换句话说是等待某事件的任务列表信息。通过查询这个列表信息可以知道有哪些任务在等待这个事件。OSEventCnt是计数器，当事件定义的是信号量或者是互斥型信号量时会用到。 从这个事件控制块的数据结构我们可以看出，它是具有抽象性质的，即可以定义成不同的事件类型，可根据具体情况进行不同类型的定义，它具有一定的通用性，又具有一定的针对性（如OSEventPtr只对邮箱或者消息队列有用）。也就是说这样的设计抽象的程序不够，存在着一定的数据冗余，比如说当事件定义成信号量时，根本用不到OSEventPtr这个变量，它就相当是一个冗余变量，这是内核设计存在的一个缺陷。 下面分析下事件控制块是如何管理其等待的任务。 首先等待一个事件的任务可能是多个，而且任务加入等待列队的时间不一样，那么又如何合理地安排它们的等待顺序呢？在内核中又是如何实现的呢？ 当一个事件发生后，该事件的等待事件列