When a thread or process is given control of a CPU, it will maintain control until it is interrupted for some reason. An I/O operation, a program exception, the time-of-day clock, or the timer ("heartbeat") interrupt, all could generate such interrupts.
Incoming interrupts are managed by a PIC, or Programmable Interrupt Controller, which is a piece of hardware that's controlled by the operating system. It prioritizes the incoming interrupts, and it can defer them. It can sense when the CPU is running with interrupts more-or-less disabled. (I say, "more or less," because the CPU can selectively disable some interrupts while enabling others.) It's possible for an interrupt to be delayed without being lost. (It's also possible that the interrupt will be lost.)
When an interrupt occurs, it is first serviced by a first-level interrupt handler, which collects status and squashes the source of the interrupt ("turns off the alarm clock so the damn thing doesn't keep ringing ..."). It then schedules, by some means, the second-level interrupt handler to be executed at some convenient time in the near future. (Think of it like a "snooze button" on that clock.) The actual implementations of this have evolved over time, but those gory details, while interesting, are not important here.
Usually, the next thing that happens is a trip to schedule.c, which is the master dispatching routine that decides "what happens next." If the scheduler decides to switch to some other unit of work, it saves the status of the unit of work that had been running previously, so that it can be restored later, thereby resuming that unit. Meanwhile, it loads the status of the unit of work that it has selected, thereby resuming that unit.
(There are many kinds of "units of work" to choose from, including threads and second-level interrupt handlers.)
Last edited by sundialsvcs; 06-22-2011 at 08:38 AM.
|