[Tinyos-2.0wg] Resource Update

[Kevin Klues]

These all sound like reasonable additions/changes to me.  If no one else has
any comments, I'll be checking it in in the morning.

Kevin

On 8/14/06, Philip Levis <pal at cs.stanford.edu > wrote:
>
> On Aug 13, 2006, at 12:17 PM, Kevin Klues wrote:
>
> >
> > interface ResourceQueue {
> >   async command uint8_t dequeue();
> >   async command error_t enqueue(uint8_t cleintId);
> > }
> >
>
> I assume the dequeue returns the client ID of the dequeued element?
> It might be useful to use a typedef here. Also, would it be good to
> have simple accessors, such as
>
> async command bool isEmpty();
> async command bool isEnqueued(uint8_t clientId);
>
> I think the first is pretty important. The second is less clear, and
> depends on the semantics of enqueue. If you are already enqueued,
> what does it return? Having the second one allows implementations to
> not have to keep state of whether they are waiting for the resource,
> as they can just query the queue.
>
> > This interface is obviously not set in stone, and could (should) be
> > changed once we come up with more uses for it.  One obvious use
> > would be to change BasicScheduler to use the FcfsResourceQueuC
> > compoent rather than implementing this queuing policy itself.
> >
> > The rest of the files simply constitute a reorganization of the
> > compoennts used to perform resource arbitration according to the
> > proposal from a few weeks back.  Basically we now have two types of
> > Arbiters (normal Arbiters and controlled Arbiters).  Normal
> > arbiters can be wired to when you don't plan on wiring a Power
> > Manager (or similar component) to the arbiter.  In the other cases
> > you want to use a ControlledArbiter.  In the previous
> > implementations, all Arbiters were essentially ControlledArbiters,
> > and this added unnecessary overhead in situations where it wasn't
> > needed.  All arbiters now provide a ResourceRequested interface as
> > well, eliminating the need for the PriorityArbiter implementation
> > that we previously had.  The PriorityArbiter component wasn't a
> > true implementation of a priority arbiter anyway, as it only
> > allowed for a single high priority user with all other users being
> > served in FIFO order.  The high priority user relied on the
> > requested() event supplied by the ResourceController interface to
> > decide when/if it should release the resource.  Combining the use
> > of the ResourceRequested interface now supplied by every arbiter
> > and a separate implementation of this strange queing policy using
> > the ResourceQueue interface, the same desired effect can be
> > obtained without having to change the internal implementation of
> > the arbiter.  If we ever do decide that a real implementation of a
> > Priority arbiter is necessary, it is simply a matter of wiring the
> > proper queuing policy to the arbiter implementation.
> >
> > I've gone through the tree and modified the necessary files to
> > adhere to the new interfaces.  This resulted in making the
> > following set of modifications....
> > 1) Resource.release() was changed from returning a void to
> > returning an error_t.  All components supplying a default
> > implementation of this command or wrapping the release command from
> > some sort of sub-resource needed to be updated.
> > 2) The Arbiter and Power Management components no longer provide an
> > Init interface.  All components wiring to this interface needed to
> > be updated.
> > 3) All components wiring an arbiter to a power manager needed to be
> > updated to instantiate an instance of a ControlledArbiter
> > implementation rather than the simple Arbiter component they were
> > previously instantiating.
> >
>
> This sounds good. My only suggested would be to name
> ControlledArbiter something else that's a bit more descriptive of
> what's going on. E.g., PowerArbiter. Or maybe just make
> ControlledArbiter Arbiters, and make Arbiters something like
> SimpleArbiter.
>
> Phil
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20060815/8fe8b816/attachment.htm