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

[Joe Polastre]

> >   void doSomething() {
> >     if( call Resource.immediateRequest() )
> >       doSomethingGranted();
> >     else
> >       call Resource.request();
> >   }
> As far as I can tell, this issue has nothing to do with the rh
> (resource handle) thing? You want an async request that immediately
> signals granted if the resource is available? (your Urgent interface
> proposal from the 1st mail? it would help to be more explicit...)

No.  If you look at the code, if

call Resource.immediateRequest() == SUCCESS

then immediately the resource is used in the function
"doSomethingGranted()".  Signalling an event is not only tedious, but
causes a task to be posted and execution delayed (if no task is
posted, the execution path looks screwy)

This is the crux of only one part of Cory's proposal.   The first set
of code was purely there to illustrate the immediateRequest semantics
that may be useful.

Cory is also proposing nesting of resources using a resource handle. 
That is a separate discussion.  In that case, when a resource is
granted, you are given a resource handle to use for subsequent
accesses to the resource.

Basically, we tried to get I2C, SPI, and UART on USART0 of the MSP430
to work concurrently in both TinyOS 1.x (haha, yeah right, like that
will work), and with the TinyOS 2.x TEP proposal.  I believe Cory is
simply relaying why neither of those proposals actually allowed I2C,
SPI, and UART requests to be submitted and run efficiently on a single
underlying piece of hardware, especially in the face of time critical
operations like SFD timestamping.  Of course, Cory will comment more
on the intricacies if you want, but I think the initial email spelled
out a lot of the concerns.

For example:

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

Any poorly written component that doesn't use the Aribiter (or uses it
incorrectly) may corrupt a process currently under execution. 
Instead, a token could be passed and then verified before a component
is permitted to use the resource.  This model is not uncommon and
allows more explicit resource sharing across layers.  Whether the
token is passed explicitly in functions or implicitly through
parameterized interfaces is an argument we could have, but not really
the main concern of the proposal.

-Joe

_______________________________________________
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