So, which function should you use?
For low-frequency interrupts, you can almost always get away with InterruptAttachEvent().
Since the interrupts occur infrequently, there won't be a significant
impact on overall system performance, even if you do schedule threads unnecessarily.
The only time that this can come back to haunt you is if another device is chained off the
same interrupt—in this case, because InterruptAttachEvent() masks the source
of the interrupt, it'll effectively disable interrupts from the other device until
the interrupt source is unmasked.
This is a concern only if the first device takes a long time to be serviced.
In the bigger picture, this is a hardware system design issue—you shouldn't
chain slow-to-respond devices on the same line as high-speed devices.
For higher-frequency interrupts, it's a toss up, and there are many factors:
- Unnecessary interrupts—if there will be a significant number of these,
you're better off using InterruptAttach() and filtering them out in the
ISR. For example, consider the case of a serial device. A thread may issue a
command saying “Get me 64 bytes.” If the ISR is programmed with the
knowledge that nothing useful will happen until 64 bytes are received from the
hardware, the ISR has effectively filtered the interrupts. The ISR will then
return an event only after 64 bytes have been accumulated.
- Latency—if your hardware is sensitive to the amount of time that passes
between asserting the interrupt request and the execution of the ISR, you should use
InterruptAttach() to minimize this interrupt latency. This is because
the kernel is very fast at dispatching the ISR.
- Buffering—if your hardware has buffering in it, you may be able to get away
with InterruptAttachEvent() and a single-entry queueing mechanism like
SIGEV_INTR and InterruptWait().
This method lets the hardware interrupt as often as it wants, while letting
your thread pick the values out of the hardware's buffer when it can.
Since the hardware is buffering the data, there's no problem with interrupt latencies.