Interrupt Handling – disabling interrupts

With legacy boards (ISA, early PCI specs), all interrupts are disabled during the execution of an interrupt handler. More current boards (with PCI-e, MSI capabilities) do not disable interrupts – but also don’t latch interrupts so they may be missed if not processed in time. Therefore, an interrupt handler should execute quickly so other interrupts are not missed.

If the servicing of an interrupt is a time-consuming activity, it should be split between an interrupt handler and a thread.

There are two common alternatives to implement the thread:

- as an interrupt thread – a concept built into INtime that connects an interrupt handler with its interrupt thread and also does all cleanup on exit

- as a “service” thread – the system designer is free to implement any sort of handler-thread interface if it uses low-level functions only. In this scenario, a low-level semaphore or mailbox is used by the interrupt handler to trigger an ordinary thread taking care about the time-consuming activities. To use a thread to “service” the time-consuming activities for the interrupt, the interrupt handler needs to carefully control thread scheduling by use of knStopRtScheduler and knStartRtScheduler. This scenario also requires the application to do all cleanup like disabling the interrupt level it used.