μC/OS-Ⅲ操作系统资源管理的直接发布与延迟发布以及信号量简述

直接发布和延迟发布也是为了解决临界区代码的问题。所以先行解释一下临界区代码。
临界区代码是指必须连续运行的一段代码，不能被中断或者任务来打断。譬如

//临界区代码开始
.......
switch(globalvalue)
case 1://do something
case 2:
case 3:
.......
.......
//临界区代码结束

globalvalue是定义的一个全局变量，如果打断了临界区代码，在中断或者其他任务修改了globalvalue的值，那么再次回到这个switch判断时，结果就不正确了。这时就需要对这段代码进行保护。

1.如果在中断或者任务中都有可能访问临界区代码，则采用关中断的方式。也即直接发布

2.如果仅仅有可能在任务中访问临界区代码，则采用延迟发布。延迟发布的优势是能大大减少关中断的时间，这样使得中断响应就会快一点。因为它把中断需要做的函数调用和相应的参数写到了一个队列中，由中断处理任务来执行它们，中断处理任务也是一个任务，这时只要把任务调度器锁定了，就可以防止其他任务访问临界区的代码了。所以关中断的时间仅仅为中断处理任务从队列中提取函数调用的时间，大大缩短了。

思考：
1.其实从本质上讲，直接发布的意思是指直接在中断服务函数里面发布消息或者信号，而延迟发布则是要先放进一个队列，然后再由一个任务来发布消息或者信号，这就相当于延迟的意思啦
2.再仔细想想怎样用延迟发布来取代直接发布，这好办。就是中断服务程序不要直接做发布函数调用，而是将函数写入到队列中去，交由中断处理任务来做函数调用。其他的中断服务程序也这么写。那也就不存在其他的中断服务程序会访问本次中断服务程序的临界区代码的问题了，所以中断关断的时间不就减少了吗，当然相应锁定任务调度器的时间就变长了，也就是等价于任务延迟时间变大了。
3.什么时候用直接发布，什么时候用延迟发布。这取决于我们的应用程序对中断响应时间和任务响应时间的要求

上述的关中断和关调度都不好用，前者拉长了中断延时，后者与μC/OS的可抢占的多任务内核相违背（因为优先级高的任务在关闭调度的时候不能得到CPU的使用权了）。最好的方式是使用信号量或者互斥型信号量。

1. 信号量
   这是一种数据结构，包含了类型、名字、等待这个信号量的任务组成的挂起表等。简要工作原理就是，当任务调用OSSemPen()函数来等待该信号量时，如果该信号量被其他任务占用，未被释放。那么该任务就会挂起等待。同时在OSSemPen()函数中可以设置超时时间，如果设置了超时时间，那么该任务也会挂在时间节拍表中。当然，和其他情形一样，会传一个err参数给OSSemPen()函数，用于判断返回的错误类型，err可以辨别是成功得到该信号量了，还是超时了，或者等待被其他任务给取消了等。
2. 互斥型信号量
   那为啥有了信号量，还要加一个互斥型信号量呢？这是因为信号量会出现任务优先级反转的现象。
   
   当任务L获得信号量时，开始执行3。此时若中断发生，任务H因为某种原因（某个信号量释放等）进入了任务就绪表中，那么中断结束将执行任务H，即执行5，5结束后，任务H需要请求信号量，而此时信号量被任务L占有，所以任务H被挂起，回到任务L继续执行3，当3执行一段后，又发生了任务M抢占CPU的情况，任务H得到信号量的等待时间就更加长了。这段时间就称之为优先级反转时间。
   所以互斥型信号就是要解决这个问题，当任务H请求获得信号量时，此时信号还在任务L这里，它会将任务L的优先级变为和任务H一样。那这时任务M就无法再抢占L的CPU使用权了。显然任务L释放信号量的时间就变快了。