取而代之的是任务调度器-read.pptVIP

演变 对很多人来说，多任务并行的机制是神秘的，包括很多长期在操作系统下开发应用程序的人来说也是如此。 回顾一下从普通的单任务顺序执行到多任务并行执行的演变过程，有利于打破“多任务并行”的神秘感。 其实多任务并行机制一点也不复杂，从技术上说，它就是程序流折断加现场（在操作系统里叫上下文）保护。这两部分技术不仅谈不上高深，甚至无法称其为“技术”，因为几乎每个开发者每天都在跟它们打交道：比较中断响应、调子程序。 那么它到底神秘在哪里呢？在于程序流反向控制机制，所谓程序流反向控制指的是，由子函数决定父函数的执行流程。对于通常的程序来说，总是由父函数决定何时调用哪一个子函数的；而在并行多任务系统里，是由一个被称为任务调度器的子函数决定着何时调用哪一个父函数！ 需要澄清一点是，这种子函数对父函数的调用并不是任意的，它只能将流程指向父函数的折断点，也就是最近一次调用任务调度器时的位置。原因很简单，因为子函数根本不知道应该从父函数的哪个地方开始执行，除非它保存了父函数在折断时的上下文。 这种“由任务调度器保存任务流程折断点信息（上下文），并在将来某个时间恢复该上下文，然后继续该任务流程”的方式，就是多任务并行的核心机制。 如何在子函数中修改父函数的执行流程？修改堆栈！ 键盘扫描 显示扫描 主程序 最简单的顺序执行方式 挨个调用任务，执行完一个任务后再执行下一个任务。 如果一个任务长时间占用CPU,那么其它任务对外部事件的响应全部停止。 主程序 显示扫描片段1 显示扫描片段2 显示扫描片段3 显示扫描片段4 延时处1 键盘扫描 延时处2 延时处3 延时处4 改进 将浪费的时间利用起来 仔细观察可发现,其实任务并非一直运行,大部分时间是在延时.如果将任务从延时处折断,分拆成小片段后插入到另一个任务中,取代原有的延时程序,就可以提高系统资源的利用率. 键盘扫描片段1 主程序 显示扫描片段1 键盘扫描片段2 显示扫描片段2 … 键盘扫描片段n 显示扫描片段n 再改进 统一调度任务片段 改由主程序来调度各任务片段.此时任务只剩下逻辑上的概念,而不存在完整的任务函数.任务函数已被分拆成若干小片. 不足之处是,任务片段之间的关系是固定的.例如执行完键盘扫描任务的片段1后,必定是运行显示扫描任务的片段1. 键盘扫描片段1 主程序 继续改进 实现流程控制---状态机 在主程序与任务之间增加一个接口:任务状态控制器.主程序 只与任务的状态控制器打交道，由状态控制器负责调用任务的片段以及控制阶段的变换。 这种循环、条件转移等大尺度流程控制在状态控制器中完成、用特定编号命名每个程序流程阶段的执行方式，就是我们常说的“状态机”. 任务状态控制 Switch(task_step) 键盘扫描片段2 键盘扫描片段3 … 显示扫描片段1 任务状态控制 Switch(task_step) 显示扫描片段2 显示扫描片段2 … 其它任务片段1 任务状态控制 Switch(task_step) 其它任务片段2 其它任务片段2 … 状态机的优点是额外占用资源少，执行效率较高。 缺点是任务被拆得支离破碎，流程不直观。而且让任务在各个状态间跳来跳去，其实处理起来并不轻松。 状态机示例 Unsigned char ks_step = 读第1行键值; Void keyscan(){ switch(ks_step){ case 读第1行://省略“键值”二字 …. ks_step = 读第2行; return case读第2行: … ks_step =读第3行 return case读第3行: …. ks_step =读第1行 return } } Unsigned char disp_step =输出第1个数码管; Void keyscan(){ switch(disp_step ){ case 输出第1个 ://省略“数码管”三字 …. disp_step =输出第2个; return case 输出第2个: … disp_step =输出第3个 return case输出第3个: …. disp_step =输出第1个 return } } Void main(){ while(1){ keyscan(); display(); } } 每次进入任务函数时只执行一个片段，然后返回，任务进度依靠状态指示器来保存。 状态指示器 每进入函数一次只执行一步即返回，让出CPU给其它任务 任务调度器 键盘扫描程序 显示扫描程序 其它任务 浮出水面 任务切换点与任务