Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Simple question that will help me understand my OS class... thanks!

Basically, why is it unsafe to have an interrupt within an interrupt? (or exception within exception)

share|improve this question
If this is for a class, you'd better talk to your professor. Nested interrupts (higher-priority interrupts interrupting lower-priority interrupt handlers) are done all the time in the real world. They do require some planning, and careful design in hardware and software. Your professor (or TA, or textbook) may have been thinking about the old IBM PC interrupt controller, which had some real deficiencies compared to other hardware at that time. – John R. Strohm Sep 17 '11 at 23:55
I agree. This question is asking why something is so that is not always so. A better question would be: When is it unsafe ... – David Schwartz Sep 18 '11 at 1:57
up vote 7 down vote accepted

There are two types of interaction between the CPU and the rest of the computer's hardware. The first type is when the CPU gives orders to the hardware, the other is when the hardware needs to tell the CPU something. The second, called interrupts, is much harder to implement because it has to be dealt with when convenient for the hardware, not the CPU. Hardware devices typically have a very small amount of RAM, and if you don't read their information when available, it is lost.

Under Linux, hardware interrupts are called IRQ's (InterruptRe quests). There are two types of IRQ's, short and long. A short IRQ is one which is expected to take a very short period of time, during which the rest of the machine will be blocked and no other interrupts will be handled. A long IRQ is one which can take longer, and during which other interrupts may occur (but not interrupts from the same device). If at all possible, it's better to declare an interrupt handler to be long.

When the CPU receives an interrupt, it stops whatever it's doing (unless it's processing a more important interrupt, in which case it will deal with this one only when the more important one is done), saves certain parameters on the stack and calls the interrupt handler. This means that certain things are not allowed in the interrupt handler itself, because the system is in an unknown state.

The solution to this problem is for the interrupt handler to do what needs to be done immediately, usually read something from the hardware or send something to the hardware, and then schedule the handling of the new information at a later time (this is called the "bottom half") and return. The kernel is then guaranteed to call the bottom half as soon as possible -- and when it does, everything allowed in kernel modules will be allowed.

share|improve this answer

The general issue is that an interrupt handler will typically manipulate data structures and it would corrupt those data structures if that same code was reentered in mid-update. However, there are many ways to organize interrupt systems and many of those ways allow nested interrupts at different priority levels. Interrupt controllers can mask off interrupts that have not yet been acknowledged by the interrupt handling code, so it is too broad a statement to say that it is "unsafe to have an interrupt within an interrupt". It will depend on the design of the interrupt controller (hardware) and the interrupt handlers (software), as well as the characteristics of the interrupting device and the meaning of the interrupt.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.