2
$\begingroup$

Consider a machine that has nested interrupts (a higher priority interrupt can interrupt a lower priority one, the current instruction's address is saved and later restored). Why would a programmer want to disable all interrupts using instructions like x86's CLI when you know that even when your code gets interrupted it will always return to what you it was doing?

To me it looks like disabling interrupts is bad for performance because a very high priority and thus very important interrupt has to be dealt with as quickly as possible and you are stalling that by disabling interrupts.

$\endgroup$
  • 2
    $\begingroup$ This seems to be a question about programming, not computer science. $\endgroup$ – David Richerby Jan 5 '15 at 18:37
  • $\begingroup$ Not just about programming, but about microcontroller programming / operating system programming. It's absolutely off-topic. $\endgroup$ – cubuspl42 Apr 7 at 17:07
3
$\begingroup$

To implement atomic routine like a semaphore, for example. When a thread call routine to gain some critical section acess, the routine needs to change the value of semaphore's variables and it must be atomic. This change cannot be interrupted otherwise other thread, or process, can use or change some values that are under some critical section. You can find more info on Andrew Tanenbaum or William Stallings book.

$\endgroup$
  • $\begingroup$ Okay, this makes sense, in some special cases this "disable all interrupts" is needed, but what about general purpose code, should you avoid using that instruction? $\endgroup$ – model world Jan 5 '15 at 19:41
  • $\begingroup$ The performance is a issue, of many others, that a S.O must to concern, but not avoid. $\endgroup$ – robot_s Jan 5 '15 at 20:01
  • $\begingroup$ In general, users are not allowed to use that kind of instruction, only kernel process. Users only access by some routine offered by kernel api. Imagine a preemptive OS that uses interruptions to schedule process and some user program disable all interrupts. If this program has some bug or for some reason needs some resource that will be only available when some interrupt arrives, it enters on infinity loop and the entire cpu will be held by this process. Even the os won't be able to gain control of cpu, only rebooting. $\endgroup$ – robot_s Jan 5 '15 at 22:20
  • $\begingroup$ Another huge reason that interrupts are disabled for that type of use is to protect against the thread owning the lock getting preempted by a rescheduling interrupt, and the amount of time the lock remains held being extended to an unacceptably long time. Another reason is that it could even lead to a deadlock, if an interrupt handler tries to acquire a lock that the interrupted thread has acquired. $\endgroup$ – doug65536 Mar 4 at 4:58

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.