[Tinyos-devel] Nested interrupts

[Philip Levis]

On Aug 13, 2007, at 2:30 PM, John Regehr wrote:

>> 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 :).

In OS circles, this is the distinction between interrupt top-halves  
and bottom-halves. E.g., the network card top-half pulls the packet  
out of the device, while the bottom half dispatches it to the right  
queue/file descriptor.

Phil