Dear David,

Thanks for your reply!

With regard to the second question, if we disallow programmers to use
assembly code and assume ncc can perform global and inter-procedural alias
analysis, can we safely conclude my aforementioned claim (programmers will
not raise data races if they obey the race-free invariant)? Sorry for my
stubbornness, because I want to perform fault analysis for nesC code.

Best regards,
Yours,
Zhifeng Lai


-----Original Message-----
From: David Gay [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 05, 2007 11:44 PM
To: Zhifeng Lai
Cc: tinyos help; Philip Levis; Zhifeng Lai
Subject: Re: [Tinyos-help] Some confusion on the classic nesC paper.

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

Reply via email to