Interrupt Priority and Nested Interrupts

Two additional concepts will complete our discussion of interrupts. First is the notion of interrupt priority. Suppose two people walk into your office at the same time. (Or, one person walks in, and before you can even look up from your desk, another one walks in.) If one of these persons is your company's biggest and most impatient customer and the other is a traveling sales person, you would handle the impatient customer's needs first and have the sales person wait. The customer has higher priority. The processor also assigns priorities to different types of interrupts. Low-speed devices like the keyboard have low priority. High-speed devices like a SCSI disk have high priority because they need a rapid response in order to function optimally.

Next, there is the notion of nested interrupts. Suppose you are reading your manual when someone walks in to ask you a question. You put down the manual, listen to the question, and then get out a reference book to try to look up the answer. As you are doing this, the phone rings—another interruption! So, you mark your place in the reference book, put it down, and answer the phone. The person standing by your desk is going to have to wait a little while. When your phone conversation is finished, you pick up the reference book again and finish answering the person's question. Once that is done and they have gone away happy, you can pick up your manual and resume reading. Think of the second interruption as being nested inside the first.

Interrupts cannot be nested infinitely deep because in general an interrupt handler can only be interrupted by a higher priority interrupt. So, if you were already on the phone when someone else tried to call you, the second caller would have to wait until you hung up from the first call. Likewise, I/O devices may be prevented from interrupting the processor right away if it is already handling a higher priority interrupt.

Traps and Faults

A trap is an event similar to an interrupt, except that instead of being triggered by an external signal, traps are triggered by the execution of processor instructions. An example is a division-by-zero operation. If a user program attempts to divide a number by zero, the execution cannot safely continue. The processor "traps," which is very much like handling an interrupt but without the time pressure. The trap handler might print an error message and terminate the user program, or it may respond in some other way, such as forcing the result of the division instruction to be zero and allowing the program to continue. Another common use of traps is when application programs make requests of the operating system. The application loads information about what it wants into a register and then uses a special trap instruction to catch the operating system's attention.

A third type of event you should know about is called a fault. A fault occurs when the hardware is asked to do something it cannot do, such as access a nonexistent memory location. (C programmers who use pointers are likely to encounter this type of "nonexistent memory" fault until their code is debugged.) Faults can also occur if the memory's error correction circuitry detects an uncorrectable error, attempts to divide a number by zero, or if the program contains an illegal machine instruction. Faults and traps are handled similarly.