Overview

Keep the following things in mind when dealing with interrupts:

• A thread can attach to only one interrupt, but it's possible to attach multiple threads to the same interrupt. When a device delivers an interrupt, the kernel notifies all the threads that are attached to that interrupt. Attaching multiple threads to one interrupt is rarely useful and can cause issues as the controller only unmasks the interrupt once all the associated threads finish handling the interrupt. If one thread doesn't handle the interrupt or takes a long time to do so, the rest of the threads get stuck waiting and won't be able to handle new events from the device.
• The IST is a regular thread; its only special requirement is to unmask the interrupt when the IST is done processing. ISTs can invoke any kernel call or library routine. An IST that takes a long time to service an interrupt only affects that particular device and not the system as a whole.
• You can pass the _NTO_INTR_WAIT_FLAGS_FAST flag in InterruptWait() to achieve lower latency. However, you can't use this flag in combination with a timeout on the blocking call.
• The priority and processor affinity of an IST determines an interrupt's latency. An IST should set its processor affinity to include the processor to which the startup code routed the interrupt. The higher the thread's priority, the lower the latency. However, a high priority also requires shorter work bursts from the thread to reduce the impact on the system.