RTEMS版权所有，转载请注明来源www.rtems.net，作者ray@rtems
%A 20.1: 介绍
%A
%A 单调周期任务指的是周期性执行的任务（就像是早上8：30上班，然后12:00吃午饭.....每天如此）。RTEMS中单调周期管理器提供了执行单调周期任务的API，这些API包括。
%A
%A rtems_rate_monotonic_create- 生成单调周期任务的周期
%A
%A rtems_rate_monotonic_ident- 获取单调周期任务ID标识
%A
%A rtems_rate_monotonic_cancel- 取消一个单调周期任务
%A
%A rtems_rate_monotonic_delete- 删除单调周期任务
%A
%A rtems_rate_monotonic_period- 启动下个周期的任务
%A
%A rtems_rate_monotonic_get_status- 获得任务状态信息
%A
%A 这些函数为使用单调周期任务调度算法（RMS）的任务提供服务。调度算法能保证计划的任务能够在指定时间范围内起动。如果要启动单调周期管理器，需要在BSP中提供时间支持。
%A 20.2.2 : 单调周期，非周期任务和随机任务
%A
%A 周期性任务必须在固定的时间间隔启动。系统启动的时间间隔称为周期。周期性的两个重要特征是他的执行周期和每次执行的时间。这两个指标也可以用来衡量任务占用处理器的比率。例如一个任务可能要求每100毫秒中执行10毫秒，那么该任务的处理器利用率就是10%。
%A
%A 相比之下，非周期任务只有一个软deadline。换句话说，deadline对于随机任务不是硬性规定的，只是要求任务在固定时间内作出响应。举例来说，一个随机任务可能用于处理终端用户的输入。
%A
%A 最后，定义随机任务是有硬实时限制和最小重复周期的任务。最小的时间间隔是任务连续执行之间的最小时间间隔。举例来说，一个随机任务可能是用来处理游戏操纵杆上的发射按钮。发射按钮的机械特性决定了两次按钮之间有一个短暂的时间差。但是必须在按钮后一个短暂的时间完成子弹的发射。
%A 20.2.3 :单调周期调度算法
%A
%A 为了保证任务的可调度性，单调周期调度算法 (RMS) 对实时系统设计者非常重要。如果所有的任务在规定时间内完成，那么任务就被认为是可调度的。RMS提供一组规则，这组规则保证调度程序能够实时的对系统进行检测，保证调度优先级最高的任务。同时，在系统超负荷运行时，RMS也会对各个进程的调度情况进行监视，保证系统的运行是可预测的。
%A
%A 在单处理器系统中，RMS为静态优先级调度算法提供了良好的保证。他是经过优化的，优化指的是对于静态优先级的任务，在同等优先级条件下，RMS调度算法会根据任务的CPU时间利用率来决定任务的先后次序。
%A
%A RMS 在任务调度的时候，对于同等优先级的任务，会优先执行时间短的任务。这种调度方式和RTMES中的同等优先级先到先服务的不同。例如，在RMS调度中，执行时间是1毫秒的任务要优先于执行时间是100毫秒的。这也是由任务的执行特性决定的，对于非周期性任务，很难估算任务的执行时间，而对于周期性任务，这就比较容易了。执行要求以他们的时期为基础的任务优先级的静态指派。 任务的时期愈短,它的优先级也愈高。 下面四个任务；
%A
%A 任务     时期 (毫秒)        优先级
%A
%A 1           100                    低
%A
%A 2           50                      中
%A
%A 3           50                      中
%A
%A 4           25                      高
%A
%A RMS要求任务1优先级最低, 任务4有最高的优先级, 和任务2和3任务 有相等的优先级,而任务一将最后实现。
%A
%A 许多应用同时具有软实时和硬实时的要求。这些应用中有硬实时要求的任务被认为是紧急任务，而软实时的任务被认为是非紧急任务，紧急任务将会被RMS优先调度。在这个时候，RMS会定义自己的调度规则，有时候非紧急任务虽然具有较高的优先级，由于不是硬实时的，也可能会被滞后调度。
%A 20.2.4 : 可调度性分析
%A
%A RTEMS中，无论系统是否负载很重，也无论程序员是否知道某个任务何时开始，RMS都能确保任务能够满足实时性。
%A 20.2.4.1: 假设
%A
%A 为 RMS 的可调度性分析规则基于下面的假定:
%A
%A 1 单调周期任务的周期是常数。
%A
%A 2 任务必须在第二次调度前结束。
%A
%A 3 任务是相互独立的，不存在依赖关系。
%A
%A 4 每个任务每次的执行时间是常数，不会因为时间变化而变化。
%A
%A 5 系统中的非周期任务是软实时的。
%A
%A 6 如果上面的条件放宽，会对实时性分析结果产生副作用解释。
%A 20.2.4.2: 处理器利用率计算法则
%A
%A 实际上，系统的实时性再好，如果任务太多，CPU过载，也会调度不过来，导致无法实现实时性。为了确保系统的实时性，RTMES中给出了可调度情况下CPU 利用率的上限。每个任务的处理器利用率U，他是任务的执行周期Ti和执行时间Ei的比率。系统的处理器利用率是所有任务利用率的累加，写成递归型式就是:
%A
%A U0 =0
%A
%A Ui=Ui-1 ＋ Ei/Ti
%A
%A 为了避免系统超负荷运算，系统中会对最大任务数进行限制，进行限制后的处理器利用率为:
%A
%A 最差情况下接近ln(2) 大约是 0.693。实际上对于随机任务，利用率可以达到0.88。
%A
%A （RTEMS的开发者以及文档的制作者在这里写了一个看上去不太正确的公式，我没有办法理解，还是大家自己查阅文档吧）根据我的估计，正确的公式应该是：
%A
%A 利用率的最大值为： Utilization = maximum_tasks * (2exp(1/maximum_tasks) - 1)
%A 20.2.4.3: 处理器利用率例子
%A
%A 下表中有三个任务，看看他们是不是可调度的：
%A
%A 任务               RMS 优先级          周期           执行时间           处理器利用率
%A
%A 1                            高                  100              15                             0.15
%A
%A 2                            中                   200             50                             0.25
%A
%A 3                             低的              300              100                             0.33
%A
%A 总的利用率是0.73，可调度上限是3*(2exp(1/3)-1)=0.779，也就是说，任务是可以调度的。
%A 20.2.4.4: 可调度规则上限-同时期限原则
%A
%A 如果任务对CPU占用率的累加和超过计算值，在一定范围内还是可调度的。这个范围被称为同时期限原则。
%A
%A 对于一组给定的独立的周期任务，如果他们同时启动时，所有任务的都能满足实时调度的时间限制，那么这些任务无论如何组合，他们总是可调度的。
%A
%A 这个规则的重点在于所有任务同时启动。