[Tinyos-devel] Nested interrupts

David Gay dgay42 at gmail.com
Mon Aug 13 15:43:22 PDT 2007


On 8/13/07, John Regehr <regehr at cs.utah.edu> 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.

Oh, I'm well aware of that option. But in some cases you might not
want to occur the cost of the deferred context (e.g., for very simple
processing). Or the jitter might precisely be due to the occasional
posting of the deferred processing ;-)

David


More information about the Tinyos-devel mailing list