I was doing some of the interrupts question online and found this Multiple choice question

How can the processor ignore other interrupts when it is servicing one

a) By turning off the interrupt request line b) By disabling the devices from sending the interrupts c) BY using edge-triggered request lines d) All of the above

The answer was (D) but I wonder how are we allowed to turn off the interrupt request line ?

What if we have a high priority interrupt that comes after ? We just ignore it ? I mean (a) seems counter intuitive for me, because I don't think under any circumstances we should be turning off the interrupt request line ?

  • $\begingroup$ I don't like answer (D). (A) is a tad better. For (B)There is a race condition so the CPU cannot reliably mask by software all the other interrupt sources. (C) Edge triggered interrupts are evil. Most (?) CPUs cannot run nested interrupts. Usually entering the interrupt service routine automatically masks the interrupt enable processor state bit which is re-enabled with the return from interrupt (RTI or equivalent) instruction. The CPU then eventually services the next pending interrupt. OSes try to spend as little time as possible in that special interrupt state. $\endgroup$ – TEMLIB Aug 22 '15 at 0:54

It depends on the processor arhitecture, but yes, most processors can turn off interrupts. Shutting them completely off is usually only done in special situations like booting or critical error handling.

More commonly, interrupts are blocked until the CPU returns from the interrupt handling routines. These routines should typically do the minimum amount of processing required, then return from interrupt to finish any work (forking down to a lower level for most of the work).

An older system I'm most familiar with, the VAX architecture, allowed for multiple interrupt levels (up to 31) and when an interrupt occurred the CPU would run at an IPL level corresponding to that interrupt. All other interrupts at or below that IPL would be blocked until the IPL was lowered below the level of pending interrupts, then the pending interrupt would be delivered. There was also a SETIPL instruction that allowed critical system code to block certain types of interrupts while critical code executed. On single processor systems this was an effective synchronization technique that prevented multiple streams from changing data structures in an uncontrolled manor (multiprocessor systems required using other techniques like spinlocks). Some problem with blocking interrupts are that multiple pending interrupts would be delivered as a single event and devices with unserviced interrupts sometimes get timeout errors. So running at elevated levels for extended periods is discouraged.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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