[Tinyos-host-mote-wg] [Tinyos-2.0wg] Resource handles

[Cory Sharp]

Hi all,

I'd like to propose some changes to the TOS2 resource arbitration. 
Below are requests (R#) and arguments (A#) for them.

R1) Allow components to share their permission

A1.1) Provide for resource reservations across a batch of commands. 
To maximize robustness, we'd like lower components to not just assume
they have access to the shared resource, but validate their access
with the arbiter.  This allows for "nesting" of arbitration requests.

There is currently no way to do this with the current arbitration
proposal.  The only options are all or none.  That is, a component
must either 1) defer *all* requests through the resource arbiter,
which could allow for unwanted shared bus usage during a sensitive
transaction, or 2) provide *no* resource arbitration guarantees.

A1.2) Allow for multiple users of a submodule to play nicely. 
Consider a Radio module for send/receive and its Control module for
ack enable/disable, etc.  Radio gets the bus and performs a number of
operations, including some Control commands.  While this is happening,
commands from other modules (application, routing, etc) that are also
using the Control module should be deferred.

R2) Allow for urgent requests that take precedence over standard requests

A2) When time stamping outgoing packets, the radio component releases
the bus, captures a start of frame delimiter interrupt, then must
reacquire the bus to put the time stamp bytes into the outgoing queue.
 Failure to do so results in corrupted/lost packets.  While we can't
expect to fully eliminate these failures, we'd like to minimize them
by allowing these requests to go to the front of the arbitration
queue.

R3) Make granting requests more efficient if the resource is
immediately available.

A3) Currently all granted events go through tasks, meaning they are
deferred even if immediately satisfiable.  This is an extension of R2
above, where we don't want urgent grants to go through the task queue
if they don't need to.

R4) Make it more apparent in the interfaces which components need to
be arbitrated

A4) It's not apparent which components expect to be arbitrated and
which components manage their own arbitration.

R5) Separate the "requested" event into a separate, optional interface.

A5) A majority of resource users will choose not to handle the
requested event, because their arbitrated usage of the resource is
essentially uninterruptable.  For the usage patterns of a component
individually arbitrating many commands, writing stub handlers can be a
tedious burden.

PROPOSAL:

P1) Pass around resource handles/tokens.  A request is immediately
satisfied if made using the token from the current resource owner. 
Otherwise, the request is deferred into the arbitration queue.  The
token RESOURCE_NONE is always invalid.  This initially seems like a
burden, but it quickly becomes a feature when you can more explicitly
follow the train of ownership and users.

P2) Create ResourceUser, ResourceUserUrgent, and ResourceRequested interfaces.

interface ResourceUser {
  command void request( uint8_t rh );
  async command uint8_t immediateRequest( uint8_t rh );
  event void granted( uint8_t rh );
  async command void release();
}

interface ResourceUserUrgent {
  async command void request( uint8_t rh );
  async command uint8_t immediateRequest( uint8_t rh );
  async event void granted( uint8_t rh );
  async command void release();
}

interface ResourceRequest {
  async event void requested( bool urgent );
}

In both the ResourceUser and ResourceUserUrgent interfaces, if
request(rh) is immediately satisfiable, granted(rh) is signalled
within the request call.  Otherwise, the requests is put either last
or next in the queue, respectively.  When release is called, if the
next user is urgent, granted is signalled within the release call,
otherwise the next grant is signalled through a new task.  Only the
true owner can release a component.  Releases by permitted non-owners
are ignored.

Interfaces that allow for outer arbitration add "uint8_t rh" as the
first parameter to arbitrated commands, such as commands on the
CC2420Control interface.   Components are not required to do this, and
can instead choose manage a separate internal queuing, such as the
commands in the SendMsg interface.

This proposal is currently derived from my direct experience with the
FCFS arbiter.  I don't know how it plays out with the round robin
arbiter.

What have other people's experiences been with the TOS2 aribiters?

- Cory

_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg