[Tinyos-devel] issue with ResourceRequested

[Eric Decker]

Here is the full story:

Device A is a GPS unit connected via serial to UART1/USART1.
B is a direct serial connect for comm off mote, serial UART1/USART1 (there
is an external
   serial mux that switches between gps serial and off card comm.
C is a SD flash card connected to SPI1/USART1.

When any of these devices is running, we use the DCO to run SMCLK.  When
none are being run we'd like to make sure that the power code knows that
the DCO isn't needed for SMCLK.

My current thinking is ResourceDefaultOwner handles the power mechanism and
making sure the clocking is modified to allow the power down.

The devices A, B, and C only get turned on when needed.  Some event or
combination of events triggers the device to do its thing.  So it is unclear
as to which device should be the default owner.  Plus I'd rather use
defaultOwner
to handle the clocking first turn issues described above.

For the time being I've added othersWaiting() to the Resource interface.
 This
allows each device to select its own release point if desired.  It doesn't
allow
any kind of priority structure.  But that seems to be more the realm of the
Arbritation queuing mechanism.

Anyway, I'd be interested in other peoples thoughts.

eric


On Sat, Aug 9, 2008 at 9:48 PM, Eric Decker <cire831 at gmail.com> wrote:

> Thanks for the reply.
> The problem is a little more complicated than what I described.  So while I
> can think
> of ways to get ResourceDefaultOwner to work but by twisting it a bit.
>
> The twist is A isn't on all the time.  When it is, after it has made some
> progress and another
> contender requests then we want A to give the resource up.
>
> So I can get ResourceDefaultOwner to work, if A isn't on then it
> immediately give up
> the resource, otherwise it can determine when to give it up.  Not too bad.
>
> But perhaps a more general solution would be along the lines of adding to
> the Resource
> interface.  I'm playing with Resource.othersWaiting().  This allows A to
> take a look when
> it wants.
>
> thoughts,
>
> eric
>
>
> On Fri, Aug 8, 2008 at 11:18 PM, Philip Levis <pal at cs.stanford.edu> wrote:
>
>>
>> On Aug 8, 2008, at 10:15 PM, Eric Decker wrote:
>>
>>  I think I've found a problem with the structure of arbitration and
>>> ResourceRequested.
>>>
>>> The purpose of ResourceRequested is to allow an owning resource user to
>>> be informed
>>> that other users have requested the resource so that the owner can
>>> release it.
>>>
>>> There appears to be a start up condition that presents a problem.
>>>  Consider
>>> three users of the resource, A, B, and C.
>>>
>>> A wants to use the resource, R, but wants to release if B or C request.
>>>  A will release
>>> and immediately re-request.  That's the plan anyway.
>>>
>>> Consider, A requests the resource but it hasn't been granted yet.  While
>>> A's grant is
>>> pending, B and C request.  Then the granting task gives A the resource.
>>>  But there
>>> currently isn't anyway for A to know that there are outstanding requests
>>> and because
>>> the requests for B and C came in prior to A actually owning the resource
>>> the
>>> ResourceRequested signal wasn't signaled.
>>>
>>> Any thoughts on how to fix this?  The corner case makes it so
>>> ResourceRequested
>>> isn't as useful as it could be.
>>>
>>
>> ResourceDefaultOwner can be used for this case.
>>
>> Note that this only allows two levels of priorities, as there's a single
>> default owner, usually the power manager. It doesn't allow, for example, A
>> always yields to B, B always yields to C. This would require knowing *who*
>> requested, though, so being able to tell if there are pending requests would
>> be insufficient.
>>
>> Phil
>>
>
>
>
> --
> Eric B. Decker
> Senior (over 50 :-) Researcher
> Autonomous Systems Lab
> Jack Baskin School of Engineering
> UCSC
>
>


-- 
Eric B. Decker
Senior (over 50 :-) Researcher
Autonomous Systems Lab
Jack Baskin School of Engineering
UCSC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080810/3ad36531/attachment.htm