Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG. Writing interrupt handlers
The kernel knows that “thread1” was running, and the ISR didn’t tell it to do anything,
so it can just go right ahead and let “thread1” continue after the interrupt.
Just for reference, here’s what the InterruptAttachEvent() function call does (note that
this isn’t the real source, because InterruptAttachEvent() actually binds a data
structure to the kernel — it isn’t implemented as a discrete function that gets called!):
// the "internal" handler
static const struct sigevent *
internalHandler (void *arg, int id)
{
struct sigevent *event = arg;
}
InterruptMask (intr, id);
return (arg);
int
InterruptAttachEvent (int intr,
const struct sigevent *event, unsigned flags)
{
static struct sigevent static_event;
memcpy (&static_event, event, sizeof (static_event));
}
return (InterruptAttach (intr, internalHandler,
&static_event, sizeof (*event), flags));
The trade-offs
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
April 30, 2009 Chapter 4 • Interrupts 185