3.2.1 Interrupt Handling

• Interrupts

• Interrupt Priority and Nested Interrupts

• Traps and Faults

Interrupts

One of the important jobs of the kernel is to handle interrupts. An interrupt is a signal to the processor that some event has occurred that requires immediate attention. Often these events are associated with an input/output operation, but there are other kinds of interrupts as well. The kernel figures out what caused the interrupt and makes an appropriate response. It must act very quickly. In order to avoid losing information when the next interrupt arrives, it must handle each interrupt in less than a thousandth of a second.

To see how interrupts are handled, let us look at how people do it. Suppose you are sitting at your desk at work, reading a manual. Maybe it is the documentation for some new software you have purchased. After you have read a few pages, a courier walks in, apologizes for interrupting you, and asks you to sign for a package. To respond to this interruption, you first place a bookmark in the manual to mark your place and then lay the manual down. Now that your hands are free, you sign for the package and place it off to the side of your desk where you will deal with it later. Then you pick up the manual again, open it to the bookmark, and resume reading.

The kernel handles interrupts in pretty much the same way. Here are the steps involved in responding to a keyboard interrupt, which occurs every time you press a key. Before you press the key, the processor is busy running some program or other. Let us assume you are using the computer to edit a Web page, and the processor is busy figuring out how to display some image file you have just loaded. While it is doing this, you reach forward to type the letters "http" on the keyboard. As soon as you hit the "h" key, the keyboard transmits a byte of data to the PS/2 keyboard interface on the motherboard. The interface then needs to interrupt the processor and hand off this byte of data to the keyboard driver. It must do this very quickly—before you hit the "t" key—otherwise there is a danger that the next keystroke will be lost.

The keyboard interface sends to the processor a signal called an IRQ (interrupt request). When the processor receives this signal, it stops executing the application program (a Web page editor in our example), making note of the address of the last instruction executed. Then, it jumps to the address of the keyboard interrupt handler, and starts executing the instructions it finds there. Because the processor's registers contain whatever data the user program was manipulating at the time, the interrupt handler must save the contents of these registers before it can use a register for its own purposes. After saving the registers, it is free to examine the state of the keyboard interface and accept the byte of incoming data. It places this byte in a storage area that will be checked by the keyboard driver the next time it runs, perhaps a millisecond from now. Then the keyboard interrupt handler restores the contents of the saved registers and transfers control back to whatever task was executing previously (the Web page editing application), resuming execution at the exact spot where the interrupt occurred. Everything is over in a few hundred microseconds; the application program has no idea that it was interrupted.