I've decided to read Operating Systems Concepts by Silberschatz, Galvin Gagne (8th edition) over the summer. I've gotten to a topic that's confusing me - interrupts and their role as it relates to operating systems.

The text says that an operating system will begin a first process such as "init" and then wait for an "event" to occur and this event is usually signaled by an interrupt. The text also says that the interrupt can come from either the hardware or the software. How does this work, in a little more detail? Is the operating system driven by interrupts?

I am just looking for some big picture understanding.


4 Answers 4


When the OS runs a process such as "init", it would have sent signals to other sub-systems/device managers etc, like the memory, I/O devices, etc. The interrupt is just a way of telling the processor or the OS that it is ready, or it has new input, etc. So sometime during init, the OS is waiting for sub-systems to be ready, and an interrupt from these sub-systems would indicate exactly that. So that is what the "event" relates to.

In regard to hardware or software interrupts, hardware interrupts are those which come from the hardware. Eg. I/O devices like keyboard, etc. A hardware interrupt causes the processor to save its state and begin execution of interrupt handler. On the other hand, software interrupts are instructions in the instruction set, which causes the processor to change its privilege level from user-supervisor, also known as context-switch. These details will be covered later on in the text book.


Interrupts allow the operating system to take notice of an external event, such as a mouse click. Software interrupts, better known as exceptions, allow the OS to handle unusual events like divide-by-zero errors coming from code execution.

The sequence of events is usually like this:

  1. Hardware signals an interrupt to the processor
  2. The processor notices the interrupt and suspends the currently running software
  3. The processor jumps to the matching interrupt handler function in the OS
  4. The interrupt handler runs its course and returns from the interrupt
  5. The processor resumes where it left off in the previously running software

The most important interrupt for the operating system is the timer tick interrupt. The timer tic interrupt allows the OS to periodically regain control from the currently running user process. The OS can then decide to schedule another process, return back to the same process, do housekeeping, etc. The timer tick interrupt provides the foundation for the concept of preemptive multitasking.


An interrupt is an "unusual" event that happens which needs to be processed immediately, regardless of whatever else is going on. I say "unusual" in quotes, because they're not necessarily unexpected or bad, but "unusual" from the point of view of the CPU because they "just happen" while it's busy executing code that may be unrelated.

The CPU has some mechanism for listening to interrupts, and some way of configuring "what to do" when interrupts of various kinds occur. This allows the operating system to arrange that it will be notified when hardware devices do things (including the all-important hardware clock, which simply generates interrupts at regular intervals). Through the CPU's interrupt handling configuration, designated code in the OS will gain control whenever interrupts happen.

The computer is in a very unpleasant state (to an application programmer) when an interrupt handler starts running; the machine was busy doing something else (which could be anything) and now the OS has been notified that "something has happened". It has to gather any other information needed to actually handle the interrupt from wherever in the machine it should be lying around and do whatever processing is required without disturbing that "could be anything" that was running on the CPU. If the OS wants to switch which application process is currently running it will have to save enough of the context to be able to restore it later (again, without disturbing that context), then load some other context, and then let the CPU resume normal execution in that context.

As mentioned, interrupts are used for getting notifications from hardware devices (the only alternative would be to periodically check them), keeping track of time and getting the guaranteed opportunity to regain control from an application process (in order to switch which application is running), recovering from application processes executing invalid instructions, and also to enable applications to make requests of the OS. These last are known as system calls. To prevent the applications from messing up the machine and each other, they normally run with the machine in "user mode", which prevents the application from doing basically anything other than reading and writing (virtual) memory already allocated to it. This means that to do anything else (reading/writing files, asking for more memory, accessing devices, etc) the application has to make a system call; it does so basically by leaving some information about what it wants to do somewhere it knows the OS will look for it, then executing a CPU instruction that causes an interrupt of the right kind. The OS can then see what the application was trying to do and determine whether it should carry out that request. This guarantee that the OS will be involved in any process' attempt to do anything that affects anything outside the process is the only way that access policies can be enforced.

So essentially, yes, the OS is driven by interrupts. An "abstract" OS bootstraps the machine into a "normal operation" state and at some point hands off control to a "normal" process. Under normal circumstances, the OS will then only regain control by handling interrupts; but since pretty much nothing interesting happens without an interrupt, the OS basically has control of everything all the time.


The operating system is driven by interrupts. This means that:

If there are no processes to execute, no I/O devices to service, and no users to whom to respond, an operating system will sit quietly, waiting for something to happen. Events are almost always signaled by the occurrence of an interrupt or a trap, a trap is a hardware interrupt generated when an invalid instruction is given, and then it returns control to the OS.

An example of an invalid instruction is when a program is trying to access another program's memory space without having a permission.

  • $\begingroup$ interrupts don't always have to be something bad or invalid as you have described $\endgroup$
    – shailesh
    May 5, 2012 at 21:44
  • $\begingroup$ i was describing the trap interrupt, as far as i know its generated due to some error or invalid instructions. thanx for the notifying me $\endgroup$
    – CodeRed
    May 5, 2012 at 21:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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