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

[David Gay]

[I think concrete examples/code would help, I'm somewhat confused as
to what the problems and proposals are...]

On 10/21/05, Cory Sharp <cory at moteiv.com> wrote:
> 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

I'm unclear what this means?

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

While runtime checking is all well and good, I'd have to ask whether
this was a major source of runtime failures, and worth the checking
effort... Also, to validate access with the arbiter requires that the
components have access to the client identity everywhere (which is
often not otherwise necessary  - look at AdcC on the atmega128 for
instance).

> This allows for "nesting" of arbitration requests.

I'm also unclear what this means. And to the extent I do guess at
something, what's missing from the ResourceUser interface?

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

Again, I'm not quite clear what this means.

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

How isn't this achieved by having a common arbiter used by the radio,
application, routing, etc?

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

I think that's readily supportable by an appropriate arbiter, no?
There's definitely no exhaustive list of desired arbiters yet...

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

You can use immediateRequest for that, followed by request if it fails.

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

Yes. I think taking a leaf from the paper, non-private components
should either have @atmostonce() interfaces (no arbitration), Resource
interfaces or be virtualised (ok, they'll probably be exceptions, but
they should be rare).

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

Sounds like a good idea. Though it does decrease the change that
components that could release a resource will.

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

I have to say I'm not convinced. Essentially every split-phase call
which isn't virtualised will end up with a client-id, no? And doesn't
this make sharing the same interfaces with virtualised services
harder?

> 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();
> }

As I said above, I don't think these two distinctions are useful
(examples otherwise appreciated).

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

This one seemed reasonable (not sure about the async or urgent bit).

> 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?

No particular problems for the mica Adc... Phil?

David

_______________________________________________
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