[Tinyos-devel] Re-initialization QueueC and PoolC

[Jan Hauer]

The 802.15.4 primitive in question is MLME-RESET which should make
sure that after the radio has been switched off  "the MAC sublayer is
then set to its initial conditions, clearing all internal variables to
their default values." (IEEE 802.15.4-2006 Sect. 7.1.9.1.3). In my
implementation I use QueueC and PoolC to allocate memory for command
frames that never leave my set of components/the radio driver. When
the next higher layer calls MLME-RESET, then after all my components
have been reset it would be convenient to call Init on these two
library to make sure their state is reset as well.

In general, resetting a component can be quite tricky (there might be
pending Tasks/Alarms/Timers/done-events). For my set of components I
use a mechanism (a "token" that is passed between components) which
makes sure that only one component is "active". A convenient
side-effect is that "inactive" components can be reset easily. Anyway,
theoretically, for resetting QueueC and PoolC an Init interface would
suffice. But I agree that adding these interfaces is really
dangerous... In fact, like Phil said, for QueueC a work around is
simply dequeueing everything in it. For PoolC it will not be so easy,
and probably my code gets a little more complex. But, I guess, unless
other people call for Init on PoolC we can leave it like it is.

Jan

On Thu, May 29, 2008 at 5:30 AM, Eric Decker <cire831 at gmail.com> wrote:
> what I find interesting is a network protocol specification is in some ways
> constraining a software system architecture.  That seems a bit off.  Nor do
> I think that is the intent of the 802.15.4 protocol definition.  Standard
> speak can be odd.  I've been through it.
>
> I think changing the behaviour of Queues and Pools is asking for trouble as
> is calling Init again.  The reset is from 802.15.4 and should be handled in
> that stack.  The intent I am sure is to put the 802.15.4 stack
> implementation back to its initial state.  Not the entire system.
>
> I think the approach where the 802.15.4 stack is told to reset and it does
> its clean up is the way to go.
>
> eric
> autonomous systems lab
> ucsc
>
>
> On Wed, May 28, 2008 at 8:16 PM, Razvan Musaloiu-E. <razvanm at cs.jhu.edu>
> wrote:
>>
>> Hi!
>>
>> On Wed, 28 May 2008, Matt Welsh wrote:
>>
>> > I'm not quibbling over the name, it's the semantics I'm worried about
>> > too. In your original message you said
>> >
>> >>  Jan wants to return the QueueC and PoolC data structures to their
>> >> initialized state, i.e., call Init on them.
>> >
>> > Which suggested that there is already an 'Init' method of some kind on
>> > the Queue and Pool interfaces, though I see now there's not...
>> >
>> > My suggestion is that there be an 'Init' or 'reset' call on the
>> > interface that does two things:
>> >
>> >   (1) First notifies any clients of the Queue or Pool that a reset is
>> > being done (via a signal), giving the clients a chance to free any
>> > references on the queue or pool; and then
>> >   (2) invokes code within QueueP / PoolP to internally reset the
>> > state assuming that the  clients' cleanup was successful.
>> >
>> > The 'cleanup' signal may be difficult to implement in general;
>>
>> I'm frequently taking messages from Pools and return them in
>> Receive.receive() and then later put back in the Pool the received
>> message.
>>
>> > fortunately I think there are few cases where this will really be
>> > needed and it could be left as a default implementation (that could
>> > leak memory, but life's tough).
>> >
>> > The other view is that you're inventing a problem here. Instead Jan
>> > should simply not use QueueC or PoolC in the stack implementation, and
>> > manage memory directly. It's true that dealing with this in general is
>> > pretty difficult and it seems the problem should not be pushed back
>> > onto Queue and Pool but rather done in the 15.4 stack.
>>
>> I agree. The current Queue in Pool are too useful to change them. :-)
>> Having other implementations that suite special needs make more sense.
>>
>> --
>> Razvan ME
>>
>> > On May 28, 2008, at 10:19 PM, Philip Levis wrote:
>> >
>> >>
>> >> On May 28, 2008, at 7:17 PM, Matt Welsh wrote:
>> >>
>> >>> Sounds like using 'init' is the wrong thing here - really you want
>> >>> a 'reset' which has the semantics of reclaiming the memory and then
>> >>> initializing the structures to their original state. Handling the
>> >>> mechanics of 'reset' would be done by the client of the Queue or
>> >>> Pool (in this case the 15.4 stack).
>> >>
>> >> The name of the operation isn't too important at this point; what's
>> >> important is its effect. Pools and Queues can have multiple clients.
>> >>
>> >> Phil
>> >
>> >
>> _______________________________________________
>> Tinyos-devel mailing list
>> Tinyos-devel at millennium.berkeley.edu
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
>
>
> --
> Eric B. Decker
> Senior (over 50 :-) Researcher
> Autonomous Systems Lab
> Jack Baskin School of Engineering
> UCSC
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
>