[Tinyos-help] Some confusion on the classic nesC paper.

[David Gay]

On 7/4/07, Zhifeng Lai <zflai at ust.hk> 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