TinyOS2.0的任务和调度----评述

推荐一篇关于TinyOS 2.0任务和调度方面的文章

TinyOS2.0的任务和调度
http://ailexy.blog.hexun.com/7850138_d.html

顺便推荐一个Blog
http://ailexy.blog.hexun.com/

对TinyOS 2.0调度介绍的比较细致，不过，也许是TEP原文带有了明显的赞成性导向，所以我们看不到对TinyOS 2.0调度设计的负面评价。对其中的一些问题，事实上我们可以进一步思考一下

调度算法和调度器的设计应该说是一个相对比较成熟的问题，在任何一本OS课本中都可以找到有关的介绍，当然如果希望做到real time schedule，还是需要多花一点力气，可能要找几篇文章来看看，现有的很多课本在这点上内容还偏向陈旧。

既然有调度，自然也就引出了调度的对象，按TinyOS 2.0的术语，称之为Task任务，在其它嵌入式OS中，也常常干脆称之为thread。遵循Oram'z Razor原则，我们可以思考一下：如果我们自己设计一个调度机制，而且要求简单到极限，你会怎么做？

作为个人的一个观点，任何一个(函数或组件)，都是一个执行体，都应该可以顺理成章的成为被调度的对象，所以极端情况就是：系统中不必存在显示的Task，因为Task而引入的各种接口显然看上去就有些累赘。

需要思考的第二点是，有了调度器和被调度的任务，那自然就有了在动态执行的任务之间提供数据交换机制的必要，在这点上，传统OS已经有了相当成熟的久经考验的机制，这就是临界区/信号量等，当然也可以包括更高级的队列/邮箱/标志/共享内存等，但我想临界区和信号量应该是必要的。由此体会，TinyOS 2.0借Parameter接口来形式上实现上述通信机制，就显得还不够完备和灵活。

也许我对TinyOS 2.0的理解有错误，但我的确认为，TinyOS 2.0更多的是实验新想法的温床，而不是面向成熟可靠的工业应用而设计。

由此也想到OpenWSN调度器的设计。现在的OpenWSN，不过是一堆可重复利用的组件库，或者你也可以简单的把它看作是个函数库方便应用开发。事实上，我一直希望在其中加入一个调度器，现在可以明确这样说，未来的OpenWSN，将让任何一个普通的C函数，都可以成为调度的对象！我始终相信这样一个原则，Simple means efficient, robust, and elegant!
.

补记：
对一个完整的OS调度而言，还应该深入考虑两个额外的但很重要的问题：
一是多个任务之间的协调；二是多个任务之间的数据交换和传递