Getting Started with QNX Neutrino - QNX Software Systems

TIME
TIME
Writing interrupt handlers
© 2009, QNX Software Systems GmbH & Co. KG.
That’s not such a great idea, because you may not need to wake up for every interrupt
that the hardware generates! Go back and look at the source example above — it
returned an event only when the modem status register on the serial port changed state,
not when a character arrived, not when a line status register changed, and not when the
transmit holding buffer was empty.
In that case, especially if the serial port was receiving characters (that you wanted to
ignore), you’d be wasting a lot of time rescheduling your thread to run, only to have it
look at the serial port and decide that it didn’t want to do anything about it anyway. In
that case, things would look like this:
Interrupt
thread 1
kernel
(resched)
thread 2
kernel
(resched)
thread 1
Control flow with InterruptAttachEvent() and unnecessary rescheduling.
All that happens is that you incur a thread-to-thread context switch to get into
“thread2” which looks at the hardware and decides that it doesn’t need to do anything
about it, costing you another thread-to-thread context switch to get back to “thread1.”
Here’s how things would look if you used InterruptAttach() but didn’t want to
schedule a different thread (i.e., you returned):
Interrupt
thread 1
kernel
ISR
kernel
(no resched)
thread 1
Control flow with InterruptAttach() with no thread rescheduling.
184 Chapter 4 • Interrupts April 30, 2009