[Tinyos-devel] ctp vs other radio clients

[Geoffrey Werner-Allen]

Doesn't the queue only get put on the path if the component wires to
AMSenderC? What happens if, as Brany asked, something like FTSP wires
straight down to (essentially) CC2420ActiveMessageC.nc (which it does
through TimeSyncC.nc)? Anything sent below the queue won't get properly
serialized, right? This could cause an unexpected EBUSY return in
AMQueueImplP.nc if the stack is busy with somthing inserted below the queue.

Best,

-gwa-

geoffrey werner-allen :: 617.694.7261 :: www.eecs.harvard.edu/~werner


On Sat, Dec 6, 2008 at 12:15 PM, Philip Levis <pal at cs.stanford.edu> wrote:

>
> On Dec 6, 2008, at 9:05 AM, Geoffrey Werner-Allen wrote:
>
>  I'm pretty sure there IS one SendState and this was my concern exactly,
>> although Om states it more clearly.
>>
>> Best,
>>
>
> There is only one instance of StateC, but why does this matter? Let's look
> at the queue code:
>
>
>        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);
>            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;
>
> AMQueueImplP (of which there is a single instance, it uses uniqueCount() to
> scale its state) only calls the lower AMSend if the queue is empty. If the
> queue is not empty, this means there is an outstanding send, so it waits for
> the underlying sendDone.
>
> Phil
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20081206/99d22527/attachment.htm