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
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
