Does an interrupt handler have to be reentrant?

Question

I'm using a static variable inside an interrupt handler, making the interrupt handler non-reentrant.

1. Is it OK to have a non-reentrant interrupt handler?
2. When a hardware interrupt is raised, does the event go in some sort of a queue and wait for the current interrupt handler call to finish or does the interrupt handler get called right away?

Thanks

PS. I'm using Linux. The programming language I'm using is C if it makes a difference.

Maurine

What OS are you using, or is this bare metal? – Spiritualism

It depends on the implementation and how the iterrupt module is handling the interrupts. But when you get an interrupt of higher order when you are in an Interrupt Service Routine, the other interrupt is serviced and then returns back to ISR to execute the older interrupt. This is called tail chaining. – Popular

@Spiritualism I'm using Linux. I'll add this to the question. – Maurine

Answer 1

The short answer is that Interrupt Service Routines are not inherently required to be reentrant. Reentrancy is only required in the case of nested interrupts. If the Operating System you use does not support nested interrupts, then you do not need to worry about reentrancy at all. If it does, you may have control over resetting the interrupt you are servicing so that you should never get a nested interrupt.

EDIT: Now that I know you're using Linux, you might find this link helpful: Can an interrupt handler be preempted by the same interrupt handler?

Essentially the answer to your question is that Linux masks an interrupt when it is asserted so that it won't preempt itself unless a specific flag is passed when registering the ISR.

Here's a relevant quote:

Interrupt handlers in Linux need not be reentrant. When a given interrupt handler is executing, the corresponding interrupt line is masked out on all processors, preventing another interrupt on the same line from being received. Normally all other interrupts are enabled, so other interrupts are serviced, but the current line is always disabled. Consequently, the same interrupt handler is never invoked concurrently to service a nested interrupt. This greatly simplifies writing your interrupt handler.

Spiritualism

The IRQF_DISABLED (old SA_INTERRUPT) flag was removed from Linux kernel since version 2.6.35. Now any ISR runs with all interrupt disabled for that cpu. – Amandaamandi

Answer 2

Can't speak for all interrupt handlers, but on a dozen platforms I've written a hardware Interrupt Service Routine (ISR) for, the mechanics were such to universally prevent re-entrant behavior.

ISRs for software interrupts, on the other hand, of the 2 I've written, were purposely made to detect and handle re-entrant activity.

As mentioned elsewhere, this is likely OS/platform dependent.

Hummocky