uCOS-II中的任务切换-图解多种任务调度时机与问题
|
【@.1 任务调度时机】 之前的一篇文章分析了具体的uCOS-II中的任务切换机制，是从函数调用的角度上分析的。这次我具体从整个程序运行的时间上来看，分析多种任务调度发生的时机。以下所有图片均可点击放大观察。 所有图中红色箭头表示中断级的任务切换，蓝色箭头表示任务级的中断切换。
1.仅有一个任务，这种情况最简单。假设时钟节拍是1000次每秒，由定时中断产生，当节拍的时钟服务程序结束时会调用OSInitExit，退出中断，其中将进行上下文切换，运行当前就绪状态优先级最高的任务，这里当然就是任务A、任务A中的代码比较简单，运行到最后时假设调用OSTimeDly(1)延时一个周期，提示系统放弃CPU控制权，这时将进行任务切换到空闲任务Idle Task。空闲任务优先级最低，是一个死循环，仅仅让一个OSIdleCtr循环一次加一。可以看出，在一个时钟节拍的间隔，这个计数器可能加不止一次。另外uCOS中还有一个统计任务，需配置打开，其中就是利用这个空闲计数器求出CPU有多少时间在空闲任务中，即有多少CPU占空比。通过图示分析可以看出，很明显虽然任务A延时一个时钟周期，1ms，但是实际上将会少于1ms的延时。这就是为什么实际的延时中或多或少都会有延时抖动的现象，下面的很多例子的延时抖动都可能比这种情况更加复杂。
2.简单的中断，这里假设有一个外部中断，在图示处打断了任务A的运行。外部中断响应后进入服务函数，中断退出时调用OSInitExit进行任务切换，回到刚才被中断的任务。所以刚才的任务A就被延后了一段时间允许，之后任务A再切换到空闲任务。很明显，这个时钟周期内空闲计数器OSIdleCtr会少加一些，最后可以统计出CPU占用率会上升一些。
3.中断函数中利用OSSemPost发送一个信号量，接受信号量的是任务B，其优先级大于任务A。于是在每次中断服务函数结束时会首先调度任务B执行，按照图中任务B的代码只有一个OSSemPend可能会有等待挂起发送，之后任务B会因为等待接受信号量而调度会任务A继续执行。图中的画出了三个外部中断分别出现在不同时期，其中第三个外部中断将导致任务B执行到一半遇到时钟节拍的产生。这时候任务B会挂起，将执行节拍中断服务程序，经过调度后会发现任务B任然处于就绪状态，所以将继续运行任务B直到结束。最后这里可以看出空闲任务在每个时钟周期被挤得更少了，所以CPU的利用率更多。
4.跟第三中情况类似，只不过这里任务B中加了一句OSTimeDly(3)延时3个时钟周期，这时可以知道，在任务B延时期间，只剩TaskA和空闲任务，他们将不会因为任务B的延时而被挂起。延时结束时，时钟节拍将首先调度延时结束处于就绪状态的任务B，之后再运行原本的任务A。这种情况也简单的表示了uCOS是怎样充分利用CPU资源的。
5.中断中调用OSTaskResume恢复任务B。这里只是想说明，Resume/Suspend跟Post/Pend的区别，前者是一旦恢复则一直运行，而后者是Post一次，Pend方运行一次。
6.当用信号量通讯时，利用任务A来发送，控制高优先级的任务B接受信号量。可以看出，任务A发送一次信号量将会时任务B调度执行，此时任务A由于优先级低，被挂起，当任务B运行一次循环后又Pend等待信号量，这时任务B被挂起，由下一个时间周期的任务A发送，周而复始。 |
