μC/OS2Ⅱ中优先级调度算法的改进及实现
使用以上方法建立就绪表之后,我们仍然可以利用原有的优先级判定表格OSUnMapTbl ( [256]) ,对最高优先级就绪任务进行查找,并且不需要象第一种方法那样增加变量。具体的查找算法如下:
if ( (OSRdyGrp[0] 0XFF) ! =0) {
y=OSUnMapTbl[OSRdyGrp[0]];
x=OSUnMapTbl[OSRdyTbl0[y]];
prio=( y 3) + x;}
else if ( (OSRdyGrp[1] 0XFF) ! =0) {
y=OSUnMapTbl[OSRdyGrp[1]];
x=OSUnMapTbl[OSRdyTbl1[y]];
prio=( y 3) + x+ 64;}
else if ( (OSRdyGrp[2] 0XFF) ! =0) {
y=OSUnMapTbl[OSRdyGrp[2]];
x=OSUnMapTbl[OSRdyTbl2[y]];
prio=( y 3) + x+ 128;}
else{
y=OSUnMapTbl[OSRdyGrp[3]];
x=OSUnMapTbl[OSRdyTbl3[y]];
prio=( y 3) + x+ 192;}
两种方法的比较
上面详细介绍了扩展μC/OS2Ⅱ内核可管理任务数目的两种方法。下面从几个方面讨论两种改进的调度算法的优劣。首先,从代码数量上看,第一种方法代码数量要远少于第二种方法,这也就意味着第一种方法的代码平均执行时间必然少于第二种方法的代码执行时间;其次,从把就绪任务放入就绪表的所用时间来看,第一种方法可以直接确定位置,将就绪任务放入就绪表,而第二种方法中,必须顺序查找,然后才能确定就绪任务在就绪表中的位置,第一种方法所用时间明显少于第二种方法;最后,从查找最高优先级就绪任务所需的时间来看,第一种方法通过变量ox和oy直接确定所有就绪任务中的哪一个任务优先级最高,而第二种方法必须从最高优先级开始顺序查找,直到找到第一个处于就绪状态的任务才结束查找,这种方法花费的时间显然要比第一种方法多。是否能够快速判定最高优先级就绪任务是整个调度算法的最关键问题,因此通过以上分析,可以看出第一种方法显然要大大优于第二种方法。
综上所述,我们在利用 μC/OS2Ⅱ源码公开的基础上,对原有的内核任务优先级调度算法进行修改,介绍了两种不同的方法把可管理任务从原来的64个增加到256个,使其可应用于多于64个任务的复杂的工程项目开发。并且通过比较得出结论,第一种算法要优于第二种算法,第一种算法在理论上更简洁清楚,并且更加易于实现,已经在实际的开发中得到应用。
- μC/OS-II就绪表算法在Cortex-M3架构上的适配设计(01-22)
- 根据μc/Os-Ⅱ就绪表算法在ARM架构上的改动(06-12)
- 嵌入式实时系统中的优先级反转问题(06-10)
- Linux 进程调度原理(04-06)
- 嵌入式系统优先级反转问题的分析 (08-14)
- 基于新信号量策略的实时提升技术(07-06)