From: klueska Date: Wed, 10 Jan 2007 08:46:52 +0000 (+0000) Subject: minor updates to TEP108 before finalization X-Git-Tag: tinyos/2.0.1~236 X-Git-Url: https://oss.titaniummirror.com/gitweb/?a=commitdiff_plain;h=39ac2e500703164049f6ed702d70aa83c8ae833e;p=tinyos-2.x.git minor updates to TEP108 before finalization --- diff --git a/doc/html/tep108.html b/doc/html/tep108.html index 447e1031..d7b763ee 100644 --- a/doc/html/tep108.html +++ b/doc/html/tep108.html @@ -311,9 +311,9 @@ ul.auto-toc {
Vlado Handziski Draft-Created:28-Mar-2005 -Draft-Version:1.6 +Draft-Version:1.7 -Draft-Modified:2006-12-12 +Draft-Modified:2007-01-05 Draft-Discuss:TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu> @@ -502,25 +502,6 @@ interface Resource { async command bool isOwner(); } -

The diagram below shows how a simple shared resource can be -built from a dedicated resource by using the Resource interface -provided by an arbiter:

-
-         /|\                    /|\
-          |                      |
-          | Data Interface       | Resource
-          |                      |
---------------------------------------------
-|               Shared Resource            |
---------------------------------------------
-         /|\                    /|\
-          |                      |
-          | Data Interface       | Resource
-          |                      |
-----------------------      -----------
-| Dedicated Resource |      | Arbiter |
-----------------------      -----------
-

A client lets an arbiter know it needs access to a resource by making a call to request(). If the resource is free, SUCCESS is returned, and a granted event is signaled @@ -548,6 +529,25 @@ check if it is the current owner of the resource. This command is mostly used to perform runtime checks to make sure that clients not owning a resource are not able to use it. If a call to isOwner fails, then no call should be made to commands provided by that resource.

+

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.:

+
+         /|\                    /|\
+          |                      |
+          | Data Interface       | Resource
+          |                      |
+--------------------------------------------
+|               Shared Resource            |
+--------------------------------------------
+         /|\                    /|\
+          |                      |
+          | Data Interface       | Resource
+          |                      |
+----------------------      ----------------
+| Dedicated Resource |      |    Arbiter   |
+----------------------      ----------------
+

An arbiter MUST provide exactly one parameterized Resource interface, where the parameter is a client ID, following the Service Instance pattern[3]_. An arbitrated component SomeNameP MUST @@ -577,11 +577,11 @@ interface ArbiterInfo { }

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:

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 @@ -907,16 +907,18 @@ to grant requests made by its clients in an FCFS fashion.

All of the default queuing policies provided in tinyos-2.x along with the respective arbitration components that have been built using them are given below:

-
-

Queuing Policies: -- FcfsResourceQueueC -- RoundRobinResourceQueueC

-

Arbiters: -- SimpleFcfsArbiterC -- FcfsArbiterC -- SimpleRoundRobinArbiterC -- RoundRobinArbiterC

-
+

Queuing Policies:

+ +

Arbiters:

+

Keep in mind that neither the implementation of an arbiter nor its queuing policy can be used to explicitly restrict access to an underlying shared resource. The arbiter simply provides a standardized diff --git a/doc/txt/tep108.txt b/doc/txt/tep108.txt index 457e44b6..307aa3f8 100644 --- a/doc/txt/tep108.txt +++ b/doc/txt/tep108.txt @@ -241,7 +241,7 @@ should be made to commands provided by that resource. 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.:: /|\ /|\ | | @@ -290,11 +290,11 @@ status of 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 @@ -634,15 +634,17 @@ All of the default queuing policies provided in tinyos-2.x along with the 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