资源共享管理：仲裁器的作用和运用

每一个共享资源都有一个仲裁器来管理哪个用户能够在给定时间使用这一资源。由于一个仲裁器就是一个控制中心，它能够知道资源是否在使用，因此它总是能够为许多其他的服务提供信息，例如为能量管理提供帮助。如图6-1所示，一个仲裁器必须提供一个参数化的Resource接口，同时提供一个ArbiterInfo接口的实例。Resource接口由希望访问资源的各个用户进行实例化。ArbiterInfo接口由希望检索资源状态全局信息（诸如资源是否在使用、谁在使用它，等等）的组件调用。一个仲裁器应该提供一个参数化的ResourceRequested接口，同时使用一个参数化的ResourceConfigure接口。它还可能提供一个ResourceDefaultOwner接口的实例或者任何用于执行特殊仲裁策略的附加接口。对于这些接口更加详细的解释如下：

图6-1 仲裁器接口示意图

1.Resource接口

仲裁器用户使用Resource接口访问共享资源。Resource接口代码参见本书第87页。

用户通过调用request（）通知仲裁器它希望访问某个资源。如果这个资源是空闲的，将返回SUCCESS，同时利用事件granted（）通知用户。如果资源被占用，则仍然会返回SUCCESS，但是该请求将根据仲裁器的排队策略加入队列。用户使用资源完毕后，将调用release（）命令，排在请求队列中的下一个用户通过granted（）事件获得通知，获准访问资源。如果一个用户在接收到granted事件前提出了多个请求，将返回一个EBUSY值，同时这些请求不能加入队列。通过使用这种策略，一个用户不能通过提出多个请求的方式独占资源队列，但是，用户仍可以通过不释放资源的方式独占资源的使用权。

用户还可以通过immediateRequest（）命令提出资源使用请求。调用immediateRequest（）可能返回SUCCESS或者FAIL，利用该命令提出的资源使用请求不会加入请求队列。如果调用immediateRequest（）时返回SUCCESS，则用户在调用返回后可立即访问资源，不用根据granted事件的通知进行访问。如果返回FAIL，则用户将不被获准访问资源，并且请求也不会进入队列。为使用资源，用户将不得不再次提出请求。

用户可利用Resource接口的isOwner命令检测自己是否是资源的当前使用者。该命令通常被用于运行检测，以确保没有占用资源的用户不能够使用该资源。如果调用isOwner失败，将不能调用资源提供的其他命令。

图6-2展示了通过正确地使用仲裁器提供的Resource接口，利用一个专有资源构建一个简单的共享资源。

一个仲裁器必须提供一个参数化的Resource接口，其参数应该是一个用户ID。一个仲裁组件SomeNameP一定包含#define SOME NAME RESOURCE，它对应一个字符串，该字符串能够传给unique（）以获取一个用户的ID。基于nesC文件的预处理方式，该#define必须放在一个单独的文件中。在nesC中，包括SomeNameP组件在内的所有组件均不能确保SomeNameP中的宏定义#define在所涉及的组件中可见。

2.ArbiterInfo接口

如图6-3所示，仲裁器必须提供一个ArbiterInfo接口的实例，该接口用于组件查询一个仲裁器的当前状态。

图6-2 Resource接口示意图

图6-3 ArbiterInfo接口示意图

与仲裁器提供的参数化的Resource接口形成对照，ArbiterInfo接口仅有一种形式。它的作用是查明如下信息。

1）仲裁资源当前是否被使用。

2）哪个用户正在使用它。

一个接口希望获得资源的本地访问权时，需要对资源状态进行观察。同时可通过观察ArbiterInfo获取资源使用情况的全局信息。

ArbiterInfo接口的首要作用是，当用户并非正在访问资源时，允许共享资源拒绝用户通过数据接口对资源进行的调用。(www.xing528.com)

3.ResourceRequested接口

且如图6-4所示，ResourceRequested接口可使一个用户长期占用一个资源，直到有其他用户需要使用该资源。使用ResourceRequested接口，ResourceRequested的信息对于资源的当前占用者可见。

图6-4 ResourceRequested接口示意图

如果其他用户通过它的Resource接口的request（）命令提出了资源使用请求，则资源的当前占用者将通过requested事件获得通知。如果请求通过immediateRequest（）命令提出，则通过immediateRequested（）事件获得通知。

一个仲裁器应该提供一个参数化的ResourceRequested接口给它的用户，但并不是必须提供。参数化的ResourceRequested接口的用户ID将与Resource接口的用户ID匹配，以确保所有事件都能通知到正确的用户。

4.ResourceConfigure接口

如图6-5所示，ResourceConfigure接口的存在允许一个用户在获准访问资源之前，对资源进行自动配置。提供ResourceConfigure接口的组件使用底层专用资源提供的接口，按照运行期望的模式对资源进行配置。一个用户连接它的共享资源抽象到该组件执行期望的配置。用户获准访问资源的同时配置命令被调用，并且反配置命令在资源释放前调用。

图6-5 ResourceConfigure接口示意图

仲裁器将使用一个参数化的ResourceConfigure接口，该接口的用户ID参数应与参数化的Resource接口的用户ID一致。如果一个仲裁器使用了ResourceConfigure接口，则在执行Resource.granted（）事件前，它必须根据赋予的用户ID调用ResourceConfigure.configure（）。类似的，在正确调用Resource.release（）之后，它必须调用ResourceConfigure.unconfigure（）释放资源。在准许用户访问资源之前调用ResourceConfigure.configure（），在释放资源之前调用ResourceConfigure.unconfigure（），可以确保对资源进行重新配置时，资源总是处于未配置状态。

ResourceConfigure接口中的命令可以作为标准Resource接口的一部分（并且转变为返回事件），但是这样做要比保持它们的独立性付出更多代价。在Resource接口中引入新的命令将导致大量的用户程序中存在冗余的配置代码。与之对应的是，如果将其作为一个独立的组件，那么用户只有在需要时才对这些代码进行实例化。

5.ResourceDefaultOwner接口

常规的Resource接口用于所有用户以平等的方式共享资源。当一个用户需要拥有其他用户不使用资源时的资源控制权时，该用户使用ResourceDefaultOwner接口。一个仲裁器一定不会提供多个ResourceDefaultOwner接口实例，它只需要提供一个ResourceDefaultOwner接口实例。

仲裁器必须保证在boot初始化完成前，ResourceDefaultOwner接口的用户是资源的拥有者。当一个普通资源用户提出资源使用情况时，ResourceDefaultOwner将接收到requested（）或者immediateRequested（）事件。然后，它必须决定是否和什么时候释放资源。一旦资源释放，所有提出请求的用户将基于仲裁器使用的排队策略依次访问资源。一旦所有的请求都进行了处理（包括在其他用户访问资源时提出的请求），ResourceDefaultOwner将自动获得资源控制权，并处理granted（）事件。ResourceDefaultOwner接口中包含和普通Resource接口中相同的isOwner（）命令，并且它们的用法完全相同。

虽然ResourceDefaultOwner接口看起来像是普通Resource接口和ResourceRequested接口的联合体，但是它的用法是完全不同的。ResourceDefaultOwner接口仅被希望在其他用户不访问资源时一直占有资源的用户使用。这些用户不主动寻求访问资源，而是利用资源空闲的时间使用资源执行操作。

定义ResourceDefaultOwner接口的首要动机是，对于一个资源及其仲裁策略，允许对其能量管理进行简便整合。如果一个仲裁器希望能够通过精确的能量管理策略对资源进行控制，它可以提供ResourceDefaultOwner接口给组件，以执行上述能量管理策略。只要资源处于空闲，能量管理组件就将接收granted（）事件，并且将资源的能量状态置于关。当其他用户请求使用资源时，能量管理器将通过requested（）或者immediateRequested（）事件获得通知。然后，它将资源的能量状态置为开，并且在执行上述步骤后释放资源。注意，如果能量打开是一个独立操作阶段（执行需要一些时间），那么在资源能量处于关状态时，用户调用immediateRequest（）将返回FAIL。