[Tinyos-help] CTP: CtpForwardingEngineP component error

Philip Levis pal at cs.stanford.edu
Mon Nov 15 10:44:18 PST 2010


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




More information about the Tinyos-help mailing list