uCOS学习笔记（三）——信号量和互斥信号量

4、关于信号量的作用

信号量（semaphore）用于实现任务间共享资源的管理、一个或多个事件的发生，比如现在有一个共享资源a，现在任务1获得访问权，那么对于其余任务来说就没有访问权限，在采用信号量时，可以这样设计，如果任务1获得访问权，那么在访问前将信号量置1，然后访问，访问结束后置0，这样，在任务1访问时，其他任务就无法访问该资源了，就实现了共享资源的管理了。

另外，在实现任务访问N个相同的资源时，将信号量初值设为N，然后在每次访问资源前，先将调用OSSemPend()函数，如果当前资源可用（信号量计数值非0），则信号量计数值减一，返回无错指示，那么根据返回值就可以进一步去访问共享资源了，在访问完共享资源后，调用OSSemPost()函数发送信号量，在函数中信号量值会加一，那么，在其他任务调用OSSemPend()函数等待信号量时，也是一样同上执行之。

但是，这里有一个问题，那就是对于多个相同资源访问时，在任务调用OSSemPend()函数后，信号量会减一，同时任务知道此时资源可用，下一步就去访问资源了，这里，信号量只可以用来表示是否允许任务去访问N个相同的资源，不能表示是否允许任务访问其中某个资源，这些资源是关联在一起的，或者说这是以后的改进方向，同时也会增加内存消耗。

5、关于互斥型信号量

互斥型信号量用于解决任务对共享资源的独占式处理。互斥型信号量不能在中断服务程序中创建，因为中断服务有最高的优先权，因而与普通任务抢占共享资源变得毫无意义，它本身可以随意访问共享资源，所以，在中断服务中建立互斥型信号量也变得毫无意义。

假设现在有三个任务A、B、C，优先级依次为8、9、10，并且都会访问同一共享资源，现在任务C得到信号量并开始访问共享资源，由于任务A的优先级最高，故剥夺任务C的CPU使用权开始执行，任务A要访问共享资源，但是共享资源现在正被任务C占用，任务A只能被挂起，等待任务C释放资源，任务C继续执行，由于当前任务B的优先级高于任务C，任务C的使用权被剥夺，任务B开始执行，直到执行完后释放CPU使用权，任务C开始执行并释放对共享资源的占用，最后任务A才获得执行。

在这种情况下，任务A优先级实际上降到了任务C的优先级水平。因为任务A要等到任务C释放占有的共享资源。由于任务B剥夺任务C的CPU使用权，使任务A的状况更加恶化，任务B使任务A增加了额外的延迟时间。任务A和任务B的优先级发生了反转。

解决之道：

一、在第一个将要访问共享资源的任务中创建mutex，并指定pip（应该比所有申请访问共享资源的任务的优先级要高，优先级的分配程序员要了然于心），在上面的案例中，假设任务C已经占用共享资源，那么任务A在访问共享资源前调用OSMutexPend，在函数中首先检查互斥信号量是否有效，然后从OSEventCnt中得到pip和现在占用共享资源任务的优先级（也就是任务C的优先级，OSEventCnt高8位为pip，这是一个很巧妙的设计，这样不同的任务在调用OSMutexPend时都可以得到pip，并且这个优先级不随着任务的删除而改变，因为它存在于OS_Event中）。

然后判断是否发生的优先级反转，若存在则将当前优先级任务就绪清除（即任务A），然后将当前任务C的优先级提升至pip，并调用OS_Sched函数使任务C就绪态，这样任务C得以继续执行以释放共享资源，在任务C执行完后调用OSMutexPost函数发现任务C的优先级被提高了，于是降低任务C优先级，并使得任务A就绪，任务A得以访问共享资源。这里，我觉得会出现这样的问题，在提高低优先级任务的优先级时，可能高优先级已经被占用，而出现更改失败，所以需要程序员对任务优先级的分配了然于心。

将任务C的优先级提高到高于任务A的优先级，相比于优先级反转时，任务A的等待延迟将会减到最少。

二、允许多任务占用同一优先级，处于同一优先级的任务执行顺序按等待先后顺序。