[Tinyos-devel] Re: Adding receive queue to AM interface

[Tony Petz]

Thanks for the answers Miklos and Andreas.  You are not missing anything,
it's just that our grasp of the internals is not great.  I followed your
lead on changing the Packet interface to be asynchronous, and I came across
this document making a case for general buffer management:

http://www.hogthrob.dk/output/technotes_files/buffer-management.pdf

Receive queues don't make sense for current platforms, but this makes a case
for adding them to support BT and 802.15.4 radios.  This requires making the
receive event asynchronous.  I haven't found anything on whether or not it's
been implemented.  It seems like a flexible buffer manager would prevent
applications from having to write their own buffer managers, and of course
it would hide the asynchronous handling requirement from the application
developers.

We are still looking for a project, and this now seems like the most viable
option.  Not sure how complicated it is yet to do this, but any advice on
the matter would be appreciated.

-tony

On 9/22/07, Miklos Maroti <mmaroti at math.u-szeged.hu> wrote:
>
> Hi Tony,
>
> > This is perhaps not the best place to ask, but I've been looking for a
> > receive queue implementation within the AM framework, and have been
> unable
> > to find one.  I'm doing a project for a grad OS class, and our proposal
> is
> > to implement a priority-based receive queue on TinyOS which will be able
> to
> > queue messages and later dispatch them to their AM handlers. Therefore
> the
> > system will no longer be susceptible to message loss if the receive
> buffer
> > is not passed back in time.  It will also remove the burden of balancing
> > queues from the application programmer.
>
> I might be missing something, but if you plan to implement receive
> queues after the ActiveMessageC via the synchronous Receive interface,
> then you will not achive much. The only way an application can hog the
> system is to do long processing in the Receive.receive event, which is
> called from a task. Now you can record the incoming messages there and
> return immediately, but if the same long processing is done in another
> task, than your Receive.receive call for the queue handling will not
> be called at at. So you cannot do this after the ActiveMessageC, and
> in fact you need to do it via asynchronous interfaces.
>
> Another, related problem I see with the Packet interfaces is that they
> are not asyncronous. I think those calls need to be made all
> asyncronous, so someone can fill/ocmpose a message in interrupt contex
> and then send in via a task later.
>
> Miklos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20070924/36d5876d/attachment.htm