uCOS-II中的任务切换-图解多种任务调度时机与问题(2)

只看该作者 · 2016-10-25 10:45

7.对于共享资源，可以采用图示方式编写。这种方式表明，当两个任务想要使用共享资源时，每个任务用Pend和Post的组合包围住想要操作的资源(比如一个函数，一个公共变量)。其中一个任务用完资源后执行Post，将会使另一个Pend等待资源的任务得以往下执行，不论二者的优先级如何。图中的任务也包含了每次时钟节拍对任务的延时作用。不过像这种信号量通讯的场合会涉及到优先级反转问题，我们后面会分析。


  8.这里演示了一个比较恶劣的中断嵌套实例，可以看出所有任务/中断级的任务调度只有等最后一层中断嵌套执行结束后才能执行，在中断嵌套中若使用Post或Resume想要执行任务调度也只能等到嵌套结束才能执行。uCOS-II支持中断嵌套，不用担心中断的响应问题，但是一旦中断嵌套之后就会出现很多延时的问题，将会导致整个系统的实时性下降，比如图示的TaskA就因为中断嵌套，并且因为中断嵌套结束后TaskB接受到信号量而执行，使得其延时效果大大超出我们想象，而且中间还缺了一步时钟周期，甚至导致这个周期满负荷(空闲任务不会执行到)。虽然画的有点夸张，但是这不得不引起我们的注意。所以通常推荐中断服务函数写的越短越好，一个好的方法是，清除了中断标志后仅仅发送一个信号量通知别的任务执行，将所有需要花时间运行的工作交给任务而不是留给中断服务函数处理。

  以上的分析包含了少量几个任务和间可能出现的常见情况，对于大型程序来说，任务的调度和中断的响应可能比这个更加复杂，需要更进一步分析。

只看该作者 · 2016-10-25 10:52

@.2 优先级反转】
  图示的情况将出现优先级反转。任务A和C需要处理一个共享资源，低优先级的任务C首先得到信号量，处理完成后Post发送信号量通知等待中的任务A得以运行，任务A处理完共享信号量后Post，将使得等待中的任务C运行，而过了一段时间，任务B由于某种原因被恢复为就绪状态，则任务B会抢夺任务C的CPU使用权，待任务B结束后任务C才得以进行，之后任务C发送信号量，通知任务A得以继续运行。
  这将会使得任务A等待信号量的时间延长，看上去是优先级低于A的任务B先于任务A执行，这往往也是我们所不希望的。这个问题的原因就是因为任务Ｃ的优先级太低，所以解决这个问题时简单的方法就是动态修改进行共享资源操作的任务的优先级即可。于是引入了互斥信号量。

  互斥信号量跟普通信号量基本一致，区别在于通过Pend得到信号量的任务将会被动态修改其优先级。这里我们一般会设置一个比较高的优先级，如图所示，任务A和任务C交替得到信号量，并且得到信号量时被赋予了一个更高的优先级。这时若任务B进入就绪状态就无法得以运行了。注意到这仅仅是uCOS-II的解决方法，因为uCOS-II不支持多任务同一优先级。

  【@.3 uCOS中的中断延时】

  对于中断响应的问题，从硬件上每个CPU并不相同，可以参考我的这篇**对ARM7系列的中断响应进行一个了解。而uCOS对于中断响应会有一套自己的办法进行统一处理。
  之前分析的内容仅仅是从任务级别来进行分析，但实际上更深入一步分析，中断的响应，任务的响应都会有一定时间的延时，以图示为例。
  当一个任务运行中得到中断请求，会首先有一个硬件的响应时间。之后硬件会关闭中断标志，一般是在CPU的状态寄存器中的IRQ位置1禁止，随后跳入中断入口地址。之后uCOS会进行自己的特殊处理，对中断进行接管。首先会保存CPU当前寄存器，并通知内核进入中断函数(一般是调用OSInitEnter函数)，之后编写代码重新打开中断，允许中断嵌套。之后将进入中断服务函数。这期间的时间就是中断响应时间。

1万 · 2016-10-25 10:53

这个系统是免费使用的吗？

只看该作者 · 2016-10-25 10:54

当服务函数结束后，会调用OSInitExit进行任务调度。若此时有新的任务置于就绪状态并且优先级比原任务高，则将会进行上下文切换，恢复CPU寄存器，中断返回后进入新的任务执行。若没有心的高优先级任务，则会原路返回，回到原来的任务继续执行。
可以很明显的看到，经过uCOS接受的中断响应将变慢，但是由于这样能实现中断嵌套和丰富的任务调度，所以这样的中断延时是可以接受的。

只看该作者 · 2016-10-25 12:51

系统里面是如何使用中断的，需要好好研究研究。