[Tinyos-2.0wg] Resource Update

[Philip Levis]

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