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?
(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? Best regards, Yours, Zhifeng Lai -----Original Message----- From: Philip Levis [mailto:[EMAIL PROTECTED] Sent: Thursday, July 05, 2007 12:11 AM To: Zhifeng Lai Cc: 'tinyos help'; 'Zhifeng Lai' Subject: Re: [Tinyos-help] Some confusion on the classic nesC paper. On Jul 4, 2007, at 8:18 AM, Zhifeng Lai wrote: > Dear all, > > I have some confusion on David and Philip's PLDI paper, "The nesC > Language: A Holistic Approach to Networked Embedded Systems": > > (1) What is the exact meaning of "whole program analysis"? Does > it mean the compiler can take all the interleavings into account? It means you're not compiling individual object files and linking them later (as you typically do in C, Java, etc.). Instead, you're compiling them all at once. This basically means that you can resolve all of the symbols. When you compile individual object files, the compiler cannot optimize across object file boundaries, because it does not know what is on the other side. > (2) Could some data race situations escape the race-free > invariant (any update to shared state is either not a data race > condition (SC only), or occurs within an atomic section)? If so, > could you give me an example? If you did something in an atomic block which broke its atomicity. For example, if you enabled interrupts within an atomic block by writing to the interrupt control register. Phil _______________________________________________ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
