Hi,
My colleagues and I have been trying to resolve an message
transmission issue with TinyOs. Our simplified scenario consists of
two Rene motes which send packets, such as our own application or even
OscilliscopeRF. We repeatedly observe that when the motes are started
at the same time, one mote (A) successfully sends packets, while the
other (B) seems to freeze. Previously, the "frozen" mote would not
start to send packets even after mote A was turned off. The timing
property seemed to indicate a race condition of some sort, so we tried
using the newest CVS version of the task scheduler, sched.c. This
helped, as mote B would start sending when mote A was turned off.
However, the fact that mote B can't send while A is sending led us to
investigate the task scheduler further.
I believe that race conditions may still exist. In the code for
TOS_schedule_task (0.6.1) and TOSH_run_next_task (1.0), there is no
critical section protection for the task queue indices *sched_full and
*sched_free. In fact, the 1.0 comments explicitly state that one is
not needed, because TOSH_run_next_task is always run in non-interrupt
context.
The task queue contains function pointers, and TOS_schedule_task and
TOSH_run_next_task run tasks by calling those function pointers. If it
were really the case that interrupts were disabled, they would still
be disabled when a function pointer is called, and a task would never
be interrupted. That would go against the reason for having tasks to
begin with.
If my tests are correct, they show that interrupts ARE enabled in
TOS_schedule_task and TOSH_run_next_task. I added the following code
to the beginning of TOS_schedule_task:
/* Check interrupt state. */
if ((inp(SREG) & 0x80) != 0) {
CLR_GREEN_LED_PIN();
}
else {
CLR_YELLOW_LED_PIN();
}
and the following to the beginning of TOSH_run_next_task:
/* Check interrupt state. */
if ((inp(SREG) & 0x80) != 0) {
TOSH_CLR_GREEN_LED_PIN();
}
else {
TOSH_CLR_YELLOW_LED_PIN();
}
and ran the former on a Rene mote, and the latter on a Mica mote. In
both cases, the green LED turns on, showing that interrupts are
enabled.
I may be missing something, and please correct me if I am. Otherwise,
I believe that the lack of critical section protection in the above
functions may be causing the race conditions we seem to be
experiencing.
Thanks, Emerson
_______________________________________________
Tinyos-users mailing list
[EMAIL PROTECTED]
http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-users
