[Tinyos-devel] Nested interrupts

[Michael Newman]

I'm with you in most ways. I would certainly do it the way you suggest IF I
could afford the latency. The really bad thing about the reentrant interrupt
is the unpredictable stack space.


You suggest:

 >wake a thread, post a task, or otherwise kick off the remaining
 >processing in a deferred context

These are hugely expensive operations (compared to fielding an interrupt).
Your latency guarantee will be ten times the reentrant interrupt or more.

I already assumed my interrupt handler was simply logging the timestamp for
later processing.

Refactoring the ISR does not solve the problem of capturing timestamps
accurately with minimum possible latency between events. Also with an ISR
that queues for later processing the minimum time between events is an
unpredictable variable length.

If you capture the timestamp and then turn interrupts back on what you have
is a fixed well understood latency  at the start of the ISR between when the
interrupt triggers and when the timestamp is captured. At the end of that
latency another event can be captured. When I say fixed latency I mean a
small exact and constant number of instructions. The fixed latency will be
less than a dozen instructions beyond the normal interrupt overhead. All
that must be done is to copy the timestamp to a stack variable and turn
interrupts back on. No conditional tests are required.

No amount of refactoring can make even close to the same guarantee. With
queuing for later processing you might get the overheads down to a small
number of hundreds of instructions. Note that in addition to the refactored
handling the interrupt exit and unwinding is part of the overhead. This is
probably the largest part of the overhead. At the cost of stack space I
think I can deliver a minimum latency between events that is between one
third and one tenth the best I could do with fast refactored code to queue
the event.

The fastest queuing I can think of is to copy the timestamp and the rest of
the event information into a dedicated ring buffer, check for overflow of
the ring buffer and update the buffer pointers. Then unwind the interrupt.
Note that unwinding the interrupt is probably the big part of this!
Difference in the minimum latency of this minimal queuing scheme is roughly
TWICE that of the reentrant interrupt.


-----Original Message-----
From: John Regehr [mailto:regehr at cs.utah.edu] 
Sent: Monday, August 13, 2007 5:31 PM
To: Michael Newman
Cc: 'TinyOS-Devel list'
Subject: RE: [Tinyos-devel] Nested interrupts

> Be very careful of one thing when using reentrant interrupts. If events
are
> put on a queue it will appear that the reentrant event occurred first! Be
> sure and dequeue them by inspecting the times to understand which occurred
> first. Do not dequeue them in the interrupt handler because the later
event
> could then be dequeued first.

Absolutely, this is nasty to even think about.

But anyway since I'm grading the exam here I'll just point out that I 
think both you and David missed a subtlety in the motivation for 
reentrancy.

Both of you identified the motivating situation as:

irq:
  do something highly time sensitive and fast
  do something not as time sensitive and relatively slow

So here we can reduce interrupt latency by enabling this interrupt after 
the first part has completed.

The question is, why not refactor the code to make the interrupt handler 
very fast:

irq:
  do something highly time sensitive
  wake a thread, post a task, or otherwise kick off the remaining
    processing in a deferred context

In this revised code, subsequent rapid-fire interrupts preempt the 
secondary processing but reentrancy no longer occurs since we're using a 
deferred context.  This is a bit less efficient but it is far easier to 
understand and has bounded worst-case stack RAM usage.

So in summary I think the case for a software design with a reentrant 
interrupt needs to say something about why the long part of the handler 
cannot be deferred.  At least, it would in any software team that I'm 
running :).

John