[Tinyos-devel] problem of using FTSP and CTP

[Philip Levis]

On Mar 20, 2009, at 5:18 PM, Miklos Maroti wrote:

>> Packet senders shouldn't wire to ActiveMessageC.Send. It forces *all*
>> senders to handle EBUSY on a virtualized interface, adding  
>> unnecessary code.
>> It breaks scheduling fairness. The hack in 1.x to deal with this  
>> was a
>> global sendDone event; let's not go back down that path.
>>
>> Or is the issue that there should be a TEP saying that if anything  
>> in your
>> system uses AMSenderC.Send you MUST NOT wire to ActiveMessageC.Send?
>
> No, I think it should be spelled out that ActiveMessageC MAY return
> EBUSY even if you did not send a message.

What is the advantage of components wiring directly to  
ActiveMessageC? Doing so raises a bunch of issues encountered in 2.1.  
For example, if you have two components sending the same AM type,  
then you need to be careful on sendDone events (you might get some  
that are not yours) and the deterministic fan-out on sendDone can  
lead to starvation.

It was a bug in FTSP to wire directly to ActiveMessageC; Brano fixed  
it, correct?

> And of course then AMQueueImplP.nc needs to be fixed to handle this
> EBUSY return value and try it again (and not just give up sending a
> message). Then the problem is not at CTP at all, any other client
> would be suspect if used together with some other protocol that uses
> ActiveMessageC directly.

What's critical here is that EBUSY denotes that there will be a  
sendDone for some AM type in the future. Otherwise, there's no  
assurance there will be a call-in, and it's not clear what the retry  
policy should be. A Timer?

Phil