频繁中断狂轰乱炸，操作系统很难招架

6

疾风知劲草，板荡识忠臣，考验洒家能耐的时刻到了！

显然，任务和信号这些概念必须保留下来，皮之不存，毛将焉附？如果没有了这些概念，所有基于信号进行控制的代码都要通通改写！且不说时间是否来得及，单是忙活多日，一觉醒来，却发现绕回了原点，洒家脆弱的心灵也颇有些难以承受。

不过，没有了ucos的框架，还要使用在其框架下的概念，就必须找出裸机形式下新的类似框架！既然是照葫芦画瓢，我们首先要提取出这颗“葫芦”的主要特征。

透过代码的重重迷雾，洒家百般搜索，千般思量，最终认定，新瓢和老葫芦的共同之处乃是：任务的数据结构和调度机制。

敲敲黑板，画画重点。任务是操作系统执行所有功能的载体，操作系统的作用无非是建立各个任务的数据结构，然后设计一个调度机制，让系统资源在这些任务的执行体里面来回切换、轮转而已。显然，新的框架要解决两个问题，“任务”的数据结构、“任务调度”机制。

在ucos的机制中，每个任务都有自己的消息队列，向该任务里发信号，就是把信号内容放到这个消息队列里。Ucos的主要调度机制是每个时钟滴答下检查一下是否存在就绪态任务，如果有，进行任务上下文切换，跳转到新任务体里执行即可。

既如此，我们完全可以设计一种“逻辑任务”，每个任务都有自己的消息队列，任务执行体里面检查自己的消息队列里是否存在新的信号，有信号就执行，和ucos下的形式一模一样。至于“任务调度”，中断太频繁，显然不可能再照搬着搞任务上下文的存储和恢复那一套了，裸机形式下的整个系统只有一个上下文，所谓调度完全可以借鉴简单操作系统里面的按时间片调度，弄成循环执行的方式，依次执行每个任务即可。

如此一来，所有控制任务的执行代码都不需要进行任何改动，穿梭在各个“逻辑任务”之间的信号依然是之前代码里定义好的那些信号，最大程度上做到了程序的复用。

更难得的是，在裸机形式的系统里，建立了任务和消息的机制，模块之间的低耦合强内聚特性得到了保留，为后续代码的开发和维护提供了大大的方便。

结语

去年桃花此门中，桃花人面相映红，人面不知何处去，桃花依旧笑春风。Ucos虽然不知跑到那里去了，但是大部分代码的骨架还在，任务-消息-模块的神韵犹在。我们唯一需要牢牢记住的只是：频繁中断狂轰乱炸，操作系统很难招架。