[Tinyos-help] A question on TinyOS scheduling

[Michael Schippling]

I'm cc'ing this back to the list to keep a record of my mistakes...

I think this's the question you asked originally isn't it?
Interrupts can come in at any time since they are almost
always caused by external events which may/not have a regular
pattern. Without specific knowledge of the hardware in question
(pretty much at the micro-second level) you can only model
them stochastically.

Then, depending on how the int handler deals with things,
interrupts may be blocked until a handler returns, or some
may be allowed to pre-empt a running handler...I'm not sure
that the ATMEGA or MSP have interrupt priority levels, so it's
more likely all or none. Most interrupts are "edge-sensitive"
in that they latch ON and don't go away until the software
does something about them -- so they stack up like planes
at an airport -- but it's not clear in what order they will
be serviced. On top of that, there is a small class of
interrupts that are "level-sensitive" and only have an effect
when their external signal is ON -- they can go away at the
whim of the external hardware if they are not serviced in
time.

So, basically, assume that there may be a concurrency issue
with any variable that is used both in a task and an event...
further analysis may show that single instruction reads
(e.g., of a 1 byte flag) won't create havoc, but just about any
mutex or condition-variable sort of operation will involve
read-modify-write which doesn't happen in a single instruction
with our controllers...

MS

Bin Lei wrote:
> Dear Michael,
> 
> Thanks a lot. I didn't go to the controller's interrupt manual coz I
> am not farmiliar with hardware and it's too hard for me :-(
> 
> I got another question with interrupt, is it possible for a device
> signal another interrupt
> before the first interrupt service routine hasn't finished execution?
> 
> I am working on an program analysis tool to find concurrent faults in
> nesC programs, and the answer is a key point. So as the previous
> question.
> 
>