Thanks for your clarification! Can I say that the reason why a sync event or sync command can't be called from async context is that sync event or command is 'unblocked' code, which may be preempted by interrupt handlers, and it isn't safe to call 'unblocked' code in block code execution context? Is it true that all the async events and async commands are only used in the interrupt handlers in TinyOS? Do the interrupt handlers have different priority levels, so that one high priority interrupt can preempt the low one?
Another question is, as you mentioned, a task can call an async command, why can't it signal an async event? Also I want to know that since Timer.fired() event is defined as sync, it isn't called in an interrupt handler, is it right? Thanks again! Yicheng -----Original Message----- From: R. Steve McKown [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 7:02 PM To: yicheng Cc: [email protected] Subject: Re: [Tinyos-help] sync and async event On Tuesday 12 September 2006 09:13 am, yicheng wrote: > > > what's the difference between 'event' and 'task'? > > > > They are different things. An event is like a callback function while > > a task is a context in which code can execute. If, for example, the > > execution context is async and a non-async event is to be signalled, > > the code posts a task which then signals the event. If, for example, > > the execution context is async and a non-async event is to be > > signaled, the code posts a task which then signals the event. > > I didn't get it. A task can't be async, 'the execution context' is an > event? I'm sorry to be unclear. An event is a function call and not an execution context. That is to say, a task can signal an event, which causes the program to execute the event signalled much like it was a function call. When the signalled event exits, control returns to the signalling code at the next instruction after the event. Similarly, code running in async context can signal async events much in the same way. However, one cannot transition from task context to async context or vice versa by signalling an event. AFAIK, the transition from task context to async context can only happen as the result of an interrupt causing control to transfer to an interrupt handler, interrupting any currently running task. Similarly, the transition from async context to task context occurs when any/all pending interrupt handlers complete, at which time TinyOS can continue execution of the task that was interrupted, start the next task in the queue, or go idle. The programmer can cause a chain of events to pass from async context to task context, by having code running in async context post a task. This was my example to you. When TinyOS gets around to executing the task, it starts in task context and it can, for example, signal a non-async event. I'm not sure if I'm really answering your question, so please let me know! One point that can be confusing is the term 'async'. The nesC compiler uses the 'async' keyword to denote code (commands, events) that can be called from async context. However, async commands can be called from tasks -- see Resource.Request() for an example. When a task calls Resource.Request(), the execution context does not change -- the Request command is still executing in the context of the task that called it. This is why I try to make the distinction between async as a nesC modifier, and async execution context. _______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
