Worried About Concurrency?
This lesson speculates how the OS handles multiple interrupts concurrently.
We'll cover the following
Some of you, as attentive and thoughtful readers, maybe now thinking: “Hmm… what happens when, during a system call, a timer interrupt occurs?” or “What happens when you’re handling one interrupt and another one happens? Doesn’t that get hard to handle in the kernel?” Good questions — we really have some hope for you yet!
The answer is yes, the OS does indeed need to be concerned as to what happens if, during interrupt or trap handling, another interrupt occurs. This, in fact, is the exact topic of the entire second piece of this course, on concurrency; we’ll defer a detailed discussion until then.
Disabling interrupts
To whet your appetite, we’ll just sketch some basics of how the OS handles these tricky situations. One simple thing an OS might do is disable interrupts during interrupt processing; doing so ensures that when one interrupt is being handled, no other one will be delivered to the CPU. Of course, the OS has to be careful in doing so; disabling interrupts for too long could lead to lost interrupts, which is (in technical terms) bad.
Locking schemes
Operating systems also have developed a number of sophisticated locking schemes to protect concurrent access to internal data structures. This enables multiple activities to be on-going within the kernel at the same time, particularly useful on multiprocessors. As we’ll see in the next piece of this course on concurrency, though, such locking can be complicated and lead to a variety of interesting and hard-to-find bugs.
Get hands-on with 1400+ tech skills courses.