如何管理TinyOS 1.x中的共享资源？

TinyOS 1.x使用两种机制管理共享资源：虚拟化和完成事件（completion events）。一个虚拟的资源以抽象的一个独立实例出现，例如TimerC的Timer接口。一个Timer实例的用户可独立使用该Timer实例，TimerC将底层硬件时钟虚拟为N个独立的定时器。

然而，一些抽象不适合进行虚拟化，程序可能需要使用物理抽象提供的控制。举个例子，TinyOS 1.x中的组件共享同一个通信协议栈GenericComm。GenericComm一个时间只能处理一个发送包。如果一个组件在GenericComm处于忙状态时试图发送一个包，那么调用将返回FAIL。此时，有包需要发送的组件需要采用一种方法获知GenericComm什么时候处于空闲状态，以便再次进行发送。TinyOS 1.x中提供一个全局完成事件，当一个包发送完成后，系统启动完成事件。基于此希望调用GenericComm的组件可以处理这个事件并且进行重发。

这方法对于物理抽象（不是虚拟抽象）来说有几个缺陷。

1）如果需要提出多个请求，必须对每次提出请求时可能返回的FAIL进行处理。这将增加程序的状态，使得程序复杂化。

2）不能对一个操作序列的运行时机进行控制。这种情况可能会对时机敏感的应用（如A/D转化器）产生影响。例如，你需要采取一些措施对ADC的使用进行预约，以实现你在期望的时刻你对ADC进行操作。(www.xing528.com)

3）即使一个硬件资源支持预约，也不能通过软件接口完成硬件资源的预约。例如，I2C总线进行多总线处理时有个“重复开始”的概念，但是在TinyOS 1.x的I2C抽象中不知道如何使用它。

4）多数TinyOS 1.x服务既没有提供一个非常便利的方法来监测抽象的可用性以便于再次使用抽象，也没有一个文档清楚地说明如何同时提出多个请求。

综上所述，采用一种方式来实现资源共享不能满足所有情况。比如，明确的资源预约可以使程序在访问A/D转换器时更好地控制访问时机，然而，当程序不需要严格地控制访问时机时（如在生物监测应用中测量温度时），资源预约不是一个必需的步骤，并且它将使程序代码更加复杂。此时使用虚拟化的方法更好一些。接下来将介绍资源的分类，一个资源抽象所使用的共享策略是依据该资源的分类确定的。