On Sep 9, 2006, at 7:33 AM, jose m wrote:
Conor Todd says that the async events can't be
interrupted by another interrupt. Philip Levis says
that te interrupts are enabled when an interrupt
declared with the INTERRUPT keyword is running (and so
every async event signalled by this one). What's the
true?
The latter.
There are two VERY SEPARATE considerations: whether code can preempt,
and whether it can be preempted. There are well established (and
accepted) reasons why low-level systems must distinguish the two
behaviors; attempts to unify them (generally) lead to problems when
implementing certain basic abstractions, and therefore the possible
benefit from unifying them is completely outweighed by the
limitations it places.
By default (tasks), TinyOS code cannot preempt other code. The async
keyword indicates that code can preempt running code. Therefore,
variables which are accessed within an async function need to have
proper protection so that data races do not occur.
By default, TinyOS code can be preempted (e.g., by async code). The
atomic keyword indicates that a statement is not preemptible (at
least, in a fashion that is not atomic). Therefore, variables which
are accessed from async code -- meaning they can have preemptive
accesses -- must be in an atomic statement or there is a data race.
Many interrupt handlers are declared so that their entire body
executes in an atomic block, therefore cannot be preempted. However,
this is determined by the call root, and not by async functions
themselves.
Examples from more traditional systems:
async POSIX signals: can preempt, cannot be preempted (signals do not
execute recursively)
interrupt handlers: in most *IX oses, an interrupt top half preempts
and cannot be preempted, while the bottom half preempts and can be
preempted
Phil
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
