Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG. Neutrino and interrupts
What if the handler needs to do a significant amount of work? Here are a couple of
possibilities:
• The amount of time required to clear the source of the interrupt is short, but the
amount of work required to talk to the hardware is long (the customer asked us a
short question that takes a long time to answer).
• The amount of time required to clear the source of the interrupt is long (the
customer’s description of the problem is long and involved).
In the first case, we’d like to clear the source of the interrupt as fast as possible and
then tell the kernel to have a thread do the actual work of talking to the slow hardware.
The advantage here is that the ISR spends just a tiny amount of time at the super-high
priority, and then the rest of the work is done based on regular thread priorities. This is
similar to your answering the phone (the super-high priority), and delegating the real
work to one of your assistants. We’ll look at how the ISR tells the kernel to schedule
someone else later in this chapter.
In the second case, things get ugly. If an ISR doesn’t clear the source of the interrupt
when it exits, the kernel will immediately be re-interrupted by the Programmable
Interrupt Controller (PIC — on the x86, this is the 8259 or equivalent) chip.
For PIC fans: we’ll talk about edge-sensitive and level-sensitive interrupts shortly.
Telling a thread to do something
We’ll continuously be running the ISR, without ever getting a chance to run the
thread-level code we need to properly handle the interrupt.
What kind of brain-damaged hardware requires a long time to clear the source of the
interrupt? Your basic PC floppy disk controller keeps the interrupt asserted until
you’ve read a number of status register values. Unfortunately, the data in the registers
isn’t available immediately, and you have to poll for this status data. This could take
milliseconds (a long time in computer terms)!
The solution to this is to temporarily mask interrupts — literally tell the PIC to ignore
interrupts from this particular source until you tell it otherwise. In this case, even
though the interrupt line is asserted from the hardware, the PIC ignores it and doesn’t
tell the processor about it. This lets your ISR schedule a thread to handle this hardware
outside the ISR. When your thread is finished transferring data from the hardware, it
can tell the PIC to unmask that interrupt. This lets interrupts from that piece of
hardware be recognized again. In our analogy, this is like transferring the VIC’s call to
your assistant.
How does an ISR tell the kernel that it should now schedule a thread to do some work?
(And conversely, how does it tell the kernel that it shouldn’t do that?)
Here’s some pseudo-code for a typical ISR:
FUNCTION ISR BEGIN
determine source of interrupt
April 30, 2009 Chapter 4 • Interrupts 171