[Tinyos-help] CTP: CtpForwardingEngineP component error

Dongyu Yang yangdy.nwpu at gmail.com
Tue Nov 16 08:56:55 PST 2010


Hello!

    I fine this is cased by the component LowPowerListeningLayerP, and this
has been fixed by mmaroti on Nov 13, 2010, Revision: r5220. And when I
update the LowPowerListeningLayerP, it is OK!
    Thanks for you attention! Best regards!


2010/11/16 Philip Levis <pal at cs.stanford.edu>

>
> On Nov 1, 2010, at 6:46 PM, Dongyu Yang wrote:
>
> > Hello!
> >
> >     The return value is EBUSY. The AM layer do not promise signal
> AMSend.sendDone
> > event, if the return value is not SUCCESS when call AMSend.send().
> >      Because in the component AMQueueImplP, when call Send.send() it may
> return
> > EBUSY in two place, as show below:
> >
> > generic module AMQueueImplP(int numClients) @safe() {
> >       provides interface Send[uint8_t client];
> >       uses{
> >             interface AMSend[am_id_t id];
> >             interface AMPacket;
> >             interface Packet;
> >       }
> > }implementation {
> >       ......
> >       command error_t Send.send[uint8_t clientId](message_t* msg, uint8_t
> len) {
> >             if (clientId >= numClients) {
> >                   return FAIL;
> >             }
> >             if (queue[clientId].msg != NULL) {
> >                     return EBUSY; //
> .................................................................................(1)
> >             }
> >             dbg("AMQueue", "AMQueue: request to send from %hhu (%p):
> passed checks\n", clientId, msg);
> >
> >             queue[clientId].msg = msg;
> >             call Packet.setPayloadLength(msg, len);
> >
> >             if (current >= numClients) { // queue empty
> >                   error_t err;
> >                   am_id_t amId = call AMPacket.type(msg);
> >                   am_addr_t dest = call AMPacket.destination(msg);
> >
> >                   dbg("AMQueue", "%s: request to send from %hhu (%p):
> queue empty\n", __FUNCTION__, clientId, msg);
> >                   current = clientId;
> >
> >                   err = call AMSend.send[amId](dest, msg,
> len);//.....................................(2)
> >                   if (err != SUCCESS) {
> >                         dbg("AMQueue", "%s: underlying send failed.\n",
> __FUNCTION__);
> >                         current = numClients;
> >                         queue[clientId].msg = NULL;
> >
> >                   }
> >                   return err;
> >             }
> >             else {
> >                   dbg("AMQueue", "AMQueue: request to send from %hhu
> (%p): queue not empty\n", clientId, msg);
> >             }
> >             return SUCCESS;
> >       }
> >      ......
> > }
> >
> >      If the EBUSY is returned from (1), it is OK, and the Send.sendDone
> event will be
> > signaled for the client who call it later; but if the EBUSY is returned
> from (2), the
> > problem arise, it do not signal the Send.sendDone event for the client
> who call it, but
> > it will only signal the Send.sendDone event for another client whose AM
> ID is different
> > from the current client later.
> >     I find this phenomenon arises when the EBUSY value return from (2).
> So it may be
> > the component AMQueueImplP have some problem, it can not guarantee the
> same
> > semantic for the EBUSY.
> >
> >
> >     Best regards!
>
> Except that EBUSY should never be returned in this case. EBUSY is only for
> when the AM layer is already sending a packet. If you're getting an EBUSY in
> (2), this implies a component is *not* going through the AM queue and
> instead directly accessing the active message layer: this breaks the queue's
> semantics and implementation.
>
> Can you determine why the active message layer is returning EBUSY?
>
> Phil
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20101117/f5e7f7ee/attachment-0001.htm 


More information about the Tinyos-help mailing list