[Tinyos-help] Simultaneous SendMsg.send()

Philip Levis pal at eecs.berkeley.edu
Wed Mar 24 15:29:56 PST 2004


On Wednesday, March 24, 2004, at 02:56 PM, efarrugi at gmu.edu wrote:

> How does SendMsg.send not being async imply that calls to it are 
> serialized through tasks? Any
> component can call SendMsg.send, just as any component can call 
> Timer.start and Timer.stop, neither
> of which are async and both of which use atomic sections to protect 
> critical sections.
>

Any command or event reachable from an interrupt must be qualified 
async.

Not any component can call SendMsg.send(). Specifically, an async 
command or event cannot call SendMsg.send(). However, SendMsg.send() 
can call async commands. The idea is that if it's async, it's safe to 
be called both from interrupt and task context, while sync can only be 
called from task context.

Timer has atomic sections because it represents a sync/async boundary. 
It has async events (the clock), which could pre-empt currently running 
sync operations. Correspondingly, atomic sections are needed.

> The docs say that the async keyword is used to demark any function 
> that can be called from a hardware event handler as a result of an 
> interrupt. Does "called" mean called directly, or can it also mean 
> indirectly from signals? In which case wouldn't every event have to be 
> async?

async propagates both through signals and commands. The only way an 
async operation can call a sync operation is to post a task. If tasks 
were an interface (something we've thought about), then their signature 
would be so:

interface Task {
   async command post();
   event run();
}

That is, Tasks are the one and only way to transition from async 
(interrupt) context to sync context.

Phil

-------

"We shall not cease from exploration
And the end of all our exploring
Will be to arrive where we started
And know the place for the first time."

- T. S. Eliot,  'Little Gidding'



More information about the Tinyos-help mailing list