Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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

To give you an impression of the level of detail I'm interested, one example. I know a system call ultimately leads to a trap which lets the processor store registers, switch to supervisor mode and perform an indirect jump. But that's only a special case (or is it?).

So what exactly happens at the hardware level when hardware or software interrupts occur, in general?

What are the differences and commonalities? How exactly do hardware and operating system cooperate to get interrupts work the way they do?

share|improve this question

A hardware interrupt takes place on a hardware level. These can be things like traps and halts, where the processor itself saves its state and waits for input or executes something else that was not necessarily part of the original program (i.e. if you divide by zero, your processor has to do something that it was not intending to do during the normal execution of the program).

Perhaps more importantly, a hardware interrupt allows a processor not to waste time in what are called polling loops. Imagine if you had to see if the user was pressing a key. There are two ways of doing that. The first is by checking very often and seeing if the key is pressed. While this will work, it is wasteful, as the vast majority of the time the check comes back negative. Interrupts allows the key press itself to change the state of the program so that it gets "notified" when a key is pressed. The second way is clearly more efficient in many cases.

A software interrupt usually means a context switch, and it done by the operating system. In some cases it means nothing more than the OS swapping which program is executing at the moment (if your computer is running 50 processes, unless you have 50 cores/threads the fact that programs simultaneous program execution is an illusion) so something similiar to the above example with the keyboard, where it is waiting for some event to occur (see more about event based programming here (from Wikipedia))

It is important to note that while in many cases interrupt based programming is a good idea, in application where there are many interrupt based programming is a good idea, if it occurs too frequently, it may be less efficient, and perhaps even crash the system.

share|improve this answer
So traps originate in the hardware and operating systems induce context switches, thank you! ;-) – artistoex Dec 5 '11 at 21:39
Not a problem. Things can get a bit tricky in some cases like when interrupts are masked and all but that is for another question I think, my answer is already long. – soandos Dec 5 '11 at 21:42

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.