LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - General (https://www.linuxquestions.org/questions/linux-general-1/)
-   -   Scheduler and timer (https://www.linuxquestions.org/questions/linux-general-1/scheduler-and-timer-887609/)

navarromoral 06-21-2011 04:28 PM

Scheduler and timer
 
Hello everybody! I would like to ask the following

- First I'll assume (please correct me) the schuduler is called periodically via an IRQ (I suppose this IRQ is the IRQ0, which is assigned to the timer).

So let's suppose thread A is running, then the scheduler is called and decides to change to thread B because the quota of thread A has expepired.

My question is: how is it possible not to return to thread A when the ISR of the timer is done (if the interrupt was raised while thread A was executing, then when the ISR is finished it should return to thread A)

And also, if interrupts are disabled, how can the scheduler be called if there are no longer timimg interrupts.

Thanks a lot in advanced!!

sundialsvcs 06-22-2011 08:34 AM

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.)


All times are GMT -5. The time now is 04:35 AM.