Since variables in async function can be preempted by another interupt, then
we need add "atomic" keyword to protect them. Unfortunately, I notice
"atomic" section is ignored in "async" function when it is converted to
"app.c" -- see following instance:
I have tried to compare SurgeM.nc with app.c under build/telosb. I notice
this "atomic" section is not atomic in app.c -- is this a bug? Or when the
atomic keyword will be ignored?
async event result_t ADC.dataReady(uint16_t data) {
atomic {
if (!gfSendBusy) {
gfSendBusy = TRUE;
gSensorData = data;
post SendData();
}
}
return SUCCESS;
}
The corresponding code in app.c is
# 222 "SurgeM.nc"
static inline result_t SurgeM$Sensor$dataReady(uint16_t data)
#line 222
{
{
}
#line 224
;
{
if (!SurgeM$gfSendBusy) {
SurgeM$gfSendBusy = TRUE;
SurgeM$gSensorData = data;
TOS_post(SurgeM$SendData);
}
}
return SUCCESS;
}
There should be "__nesc_atomic_t __nesc_atomic = __nesc_atomic_start();" to
replace "atomic". How to explain this? A bug???
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Philip
Levis
Sent: Sunday, September 10, 2006 2:31 PM
To: jose m
Cc: [email protected]
Subject: Re: [Tinyos-help] interrupts and async events question
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
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
