On 7/4/07, Zhifeng Lai <[EMAIL PROTECTED]> wrote:
Dear Philip,
(1) Yes, I see. Another question relates to this: you said that the call
graph of nesC code is fully known at compile-time. I conjecture that the
component diagrams can be treated as call graphs in programming literature,
and since the wiring relationships among components are totally determined,
the call graph is also determined at compile-time. Could you confirm my
understanding?
Essentially, yes.
(2) I understand what you mean. However, I think in the application level,
there is no primitives that can alternate interrupt enable bits. So, does it
mean application developers will not raise data races if they obey the
race-free invariant?
The atomic section is arbitrary C code, and C (well, gcc) allows you
to insert arbitrary assembly code. So your statement "n the
application level, there is no primitives that can alternate interrupt
enable bits" is incorrect (e.g., on a mica2, asm("sei") would enable
interrupts).
Furthermore, to get back to the orignal question, the data-race
detector is simplistic and does no alias analysis. So updates via
pointers are not checked to see whether they can cause races.
David Gay
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
