:TEP: 108
:Group: Core Working Group
:Type: Documentary
-:Status: Draft
+:Status: Final
:TinyOS-Version: 2.x
:Authors: Kevin Klues, Philip Levis, David Gay, David Culler, Vlado Handziski
-:Draft-Created: 28-Mar-2005
-:Draft-Version: $Revision$
-:Draft-Modified: $Date$
-:Draft-Discuss: TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu>
-
.. Note::
This memo documents a part of TinyOS for the TinyOS Community, and
The diagram below shows how a simple shared resource can be
built from a dedicated resource by using just the Resource interface
-provided by an arbiter.
+provided by an arbiter.::
/|\ /|\
| |
}
In contrast to the parameterized Resource interface provided by an arbiter,
-only a single ArbiterInfo interface is provided. Its purpose is
+only a single ArbiterInfo interface is provided. Its purpose is
to allow one to find out:
- Whether the resource for which it is arbitrating use is currently in use or not
-- Which client is using it.
+- Which client is using it.
One can view ArbiterInfo as an interface for obtaining global information about
the use of a resource, while Resource can be viewed as an interface for obtaining
respective arbitration components that have been built using them are
given below:
- Queuing Policies:
- - FcfsResourceQueueC
- - RoundRobinResourceQueueC
+Queuing Policies:
+
+- FcfsResourceQueueC
+- RoundRobinResourceQueueC
- Arbiters:
- - SimpleFcfsArbiterC
- - FcfsArbiterC
- - SimpleRoundRobinArbiterC
- - RoundRobinArbiterC
+Arbiters:
+
+- SimpleFcfsArbiterC
+- FcfsArbiterC
+- SimpleRoundRobinArbiterC
+- RoundRobinArbiterC
Keep in mind that neither the implementation of an arbiter nor its
queuing policy can be used to explicitly restrict access to an