When an interrupt occurs, an operating system
1997
When an interrupt occurs, an operating system
- A.
ignores the interrupt
- B.
always changes state of interrupted process to 'blocked' and schedules another process
- C.
always resumes execution of interrupted process after processing the interrupt
- D.
may change the state of interrupted process to 'blocked' and schedule another process
Attempted by 142 students.
Show answer & explanation
Correct answer: D
Concept. An interrupt is an asynchronous signal that forces the CPU to pause the currently running process and run an interrupt service routine (ISR). Handling an interrupt is mandatory, but the state of the interrupted process afterwards is not fixed: once the ISR returns, control passes to the scheduler, which decides — based on why the interrupt happened — whether to resume that process, preempt it, or block it. So the outcome is conditional, captured by the word “may”, never “always”.
Application — what actually happens, step by step.
Hardware saves the current CPU state (program counter, registers) of the running process and switches to kernel mode.
Control jumps to the ISR, which services the device or event that raised the interrupt.
When the ISR returns, control passes to the operating system scheduler, not blindly back to the interrupted process.
The scheduler evaluates the situation and chooses one of three outcomes for the interrupted process: (a) resume it (a routine timer tick with slice remaining, or an unrelated device event); (b) move it to ready and preempt it so a now-runnable higher-priority process can run; or (c) move it to blocked only if that process itself must now wait on a resource, then dispatch another process.
State right after the ISR (the reported doubt). By the time the ISR finishes, the interrupted process is generally in the ready state — it is runnable and simply waiting for the scheduler to pick it again; it is not automatically “blocked”. It becomes blocked only in case (c) above, i.e. when that very process is waiting on an event or resource. This is exactly why an unconditional “always blocked” claim is wrong.
Contrast with the distractors.
Discarding the interrupt: never an option — the OS would lose hardware events and control.
always → blocked and switch: false, because most interrupts (e.g. a timer tick with slice remaining) do not block the process.
always resume: false, because a higher-priority wake-up can preempt the interrupted process instead of resuming it.
may change state and schedule another: correct — it allows both blocking-and-switching and plain resumption, matching real scheduler behavior.