Getting Started with QNX Neutrino - QNX Software Systems

TIME
TIME
© 2009, QNX Software Systems GmbH & Co. KG. Writing interrupt handlers
(like “faster” or “better”) probably won’t suffice. We’ll need to look at a few pictures
and scenarios.
Here’s what happens when we use InterruptAttach():
Interrupt
thread 1
kernel
ISR
kernel
(resched)
thread 2
Control flow with InterruptAttach().
The thread that’s currently running (“thread1”) gets interrupted, and we go into the
kernel. The kernel saves the context of “thread1.” The kernel then does a lookup to see
who’s responsible for handling the interrupt and decides that “ISR1” is responsible. At
this point, the kernel sets up the context for “ISR1” and transfers control. “ISR1”
looks at the hardware and decides to return a struct sigevent. The kernel notices
the return value, figures out who needs to handle it, and makes them READY. This
may cause the kernel to schedule a different thread to run, “thread2.”
Now, let’s contrast that with what happens when we use InterruptAttachEvent():
Interrupt
thread 1
kernel
(resched)
thread 2
Control flow with InterruptAttachEvent().
In this case, the servicing path is much shorter. We made one context switch from the
currently running thread (“thread1”) into the kernel. Instead of doing another context
switch into the ISR, the kernel simply “pretended” that the ISR returned a struct
sigevent and acted on it, rescheduling “thread2” to run.
Now you’re thinking, “Great! I’m going to forget all about InterruptAttach() and just
use the easier InterruptAttachEvent().”
April 30, 2009 Chapter 4 • Interrupts 183