1888_关于多任务调度的一些整理与思考

         全部学习汇总： g_embedded: 嵌入式通用技术学习笔记 (gitee.com)

         让我想来对此做一下总结思考的书其实不是嵌入式或者至少不限于嵌入式，但是我的主业是嵌入式，对于问题的理解点暂时也是在这个领域。后续，这些知识对我自己能够产生作用的地方应该还是嵌入式。姑且把笔记放在这里。

         上面这段话是截取自《UNIX编程艺术》一书的，这种书略微看一点有时候会让我产生对自己的怀疑：我究竟是不是软件工程师？看起来，距离这些老牌黑客或者书中描述的真的软件工程师我还有很大的差距。

         之前做基于RTOS的软件开发的时候就已经了解了cooperative、preemptive两种模式。后者现在是很多RTOS的一个大卖点，而我第一次接触到这种概念还是在ucos这个系统上。对我来说，两者的差异点是在于高优先级的任务就绪之后是否可以中断正在执行的低优先级任务。

         这里的任务，在文中应该就是进程的概念。在这里提到了协同式多任务的缺点：可能缺少周期性时钟中断，或者内存管理单元。如果是在RTOS这样的微内核的角度考虑，可能是说这种任务会缺少一个周期性中断。我觉得他这里的周期性中断应该就是说系统的tick时钟，在这个时钟脉动驱动下可以进行CPU资源的分配。不过，这种设计似乎又跟我接触到的RTOS的设计有所不同，我接触到的RTOS都有一个tick，它们会借助于这个tick来管理很多时间概念。

         想到了这里，其实我多少理解了为什么会有这样的区分度。其实，RTOS，尤其是嵌入式的RTOS在使用场景上跟我们PC或者server所要处理的内容有着比较大的差异。尤其是在很多通信相关的时序上，嵌入式的要求显然是更严苛的。而对应通用计算机来说，计算机处理的事情显示到我们的交互体验上最多是处理快慢的一个差异。由于这样的一个区分度，其实我倒觉得类似于DOS这样的顺序加载器在一定程度上考虑其实或许还是适用于某些嵌入式的控制的。

       UNIX上引入这样的机制会有什么好处呢？其实，这个好处也是很容易考虑清楚的。如果是类似于顺序加载的情况，或者是协同式的任务处理，那么用户在处理多个大型任务的时候或许会觉得有一些任务在一定的时间范围内没有什么处理的进展。这样给用户的体验或许是不好的。而抢占的模型中，有一个同优先级共享时间片分派的设计，这种设计会让用户不再有这种体验上的缺憾。如果是针对优先级本来就有着很大区分度的任务来说，抢占式的处理肯定会有更好的体验效果。因为，感受上来说，高优先级的任务的确是得到了优先的对待。因此，综合看来，这种设计在嵌入式系统以及unix中想要达到的效果基本上是一致的。不过，嵌入式的系统有着自己更加侧重的考虑因素。