1
$\begingroup$

Imagine a uniprocessor system with a simple operating system with non-threaded processes and basic virtual memory (paging, no segmentation, no replacement to disk, etc).

Now assume a simple preemptive scheduler, round-robin, for example.

Because it is a uniprocessor, the scheduler must hand over control of the processor momentarily for any other processes it schedules to run. How does it regain control? It can't generate interrupts, as it is not running.

I originally assumed there must be some kind of register containing the time to return control to the scheduler, and a register pointing to the location of the scheduler. But if these registers existed, what would a nonpreemptive scheduler do with them? How would the processor know the difference between a preemptive and nonpreemptive scheduler, i.e. how would it know whether to use the registers to return, or allow the process to run to completion?

$\endgroup$
1
$\begingroup$

Your idea of interrupts is correct, but not how it works. The scheduler program will not raise an interrupt.

Let's take the round robin algorithm you have mentioned. A process is going to run for a period of time and then is supposed to relinquish the CPU. How does this work? Interrupt. It is the operating system that raises this interrupt using what is called an interval timer. The interval timer is programmable and is set to the time slice value of the round robin algorithm.

Once the interrupt is raised, the time quantum for the current process expires and the control is given to the scheduler process.

$\endgroup$
  • $\begingroup$ So is the interval timer separate from the CPU? It is my understanding that on a uniprocessor system with no threading and only one core, only one process can be running at a time, so the OS can't possibly be running to be able to generate the interrupt. Is the interrupt generated by the interval timer, which is presumably set before switching to the process in question? $\endgroup$ – Dylan Jager-Kujawa Apr 11 '16 at 3:45
  • $\begingroup$ Correct understanding. The timer does not require CPU time for execution. $\endgroup$ – kauray Apr 11 '16 at 3:56
  • $\begingroup$ Presumably the timer interrupt must be maskable, otherwise there would be huge overhead switching between the process and the operating system, should the scheduler decide to allow the process to continue execution. But how does the operating system know when to stop ignoring the timer interrupt request and actually take back control? Or am I misunderstanding maskable vs nonmaskable interrupts? $\endgroup$ – Dylan Jager-Kujawa Apr 11 '16 at 3:59
  • 1
    $\begingroup$ After being pointed in the direction of timer interrupts, I found my answer. The timer interrupt occurs at a specified interval, which (depending on hardware support) can be set to a certain interval, either statically in the kernel, or dynamically increasing/decreasing as the number of processes running and the desired latency. $\endgroup$ – Dylan Jager-Kujawa Apr 11 '16 at 4:25

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.