时间片调度法设计方案分析

引言
　　笔者曾在本刊2008年12期上发表过一篇文章——《基于μC/OS-11的时间片调度法设计》，近期在网络上看到有很多感兴趣的技术同行作了大量引用和转载。根据在实际项目中的应用经验，有必要对其再议，主要原因如下：①多任务的时间片调度在嵌入式领域有实用价值。一方面是很多嵌入式软件系统升级有这种需求，旧的软件模块基于Endless Loop实现，升级到μC/OS-II后，若要最大限度地复用旧的软件模块，时间片调度算法是实现旧的设计模式到新架构之间最简单的桥梁。另一方面，对于控制领域，存在大量的耗时任务无法自动释放控制权，时间片调度降低了任务设计的复杂度。刚刚发布不久的μC/OS-II，推出的重大改进之一就是增加了对Round Robin的支持，更是表明μC/OS-II的使用者们对该功能的实际需求是切实存在的。
　　②不更改μC/OS-II内核代码实现时间片调度。《基于μC/OS-II的时间片调度法设计》对OS内核代码作了修改，虽然很少但增加了系统耦合度，对日后的项目维护和第三方升级都是不利的。如果存在完全不用更改内核而仅基于OS服务的正常调用的实现方案，对系统的可靠性和移植性都是有益的。
　　③相对μC/OS-III，μC/OS-II仍然有广泛的应用领域。μC/OS-III作出了重大的改进，增加了时间片调度，扩展了任务数的限制，允许了同等优先级任务的存在，更多新特性的引入带来了内核结构的重整以及运行时开销的增加。虽然可以通过配置优化系统，但就大部分的应用而言，μC/OS-II完全能够胜任，至少不需要仅仅为了时间片调度功能而选用μC/OS-III.
　　1调度原理
　　该调度算法对系统的要求有两点：首先要建立一个额外的调度任务用于管理待调度的用户任务时间片计时及其切换，我们将其命名为TaskRB_Scheduler；其次是保证其任务优先级高于所有的待调度时间片任务，保证调度任务能抢占所有被调度任务的控制权。
　　我们假设系统中有3个任务需要分享时间片，分别为TaskRB_1、TaskRB_2、TaskRB_3.为了实现时间片的调度功能，还需要额外的调度任务TaskRB Scheduler，于是系统中的将会有4个任务。其中，TaskRB Scheduler由初始化代码创建，而待调度的3个用户任务的创建和管理完全由TaskRB Scheduler任务来完成。
　　TaskRB_Scheduler的运行分为两个阶段：首先是初始化阶段，负责所有时间片任务的创立并确保其处于Suspend状态；然后是调度运行阶段，如图