5
$\begingroup$

I'm having difficulty understanding what my book is trying to say in regards to preemptive and non-preemptive CPU scheduling.

It says the following:

CPU Scheduling decisions may take place under the following four circumstances:

  1. When a process switches from the running state to the waiting state (for example, I/O request..)

  2. When a process switches from the running state to the ready state (for example, when an interrupt occurs)

  3. When a process switches from the waiting state to the ready state (for example, completion of I/O)

  4. When a process terminates

In circumstances 1 and 4, there is no choice in terms of scheduling. A new process (if one exists in the ready queue) must be selected for execution. There is a choice, however, in circumstances 2 and 3.

When scheduling takes place only under circumstances 1 and 4, we say that the scheduling scheme is non-preemtive; otherwise, the scheduling scheme is preemptive. Under nonpreemptive scheduling, once the CPU has been allocated to a process, the process keeps the CPU until it releases the CPU either by terminating or by switching to the waiting state.

It is mainly the bolded part that confuses me. What does it mean by there "being a choice"? The way it's worded almost sounds like it's saying that in circumstances 2 and 3, a new process DOESN'T have to be selected for execution. I'm not quite sure I follow at all what this section of my book is trying to tell me, especially the bolded part.

$\endgroup$
  • $\begingroup$ plz cite the ref $\endgroup$ – vzn Nov 20 '15 at 18:19
7
$\begingroup$

In circumstances 1 and 4, the current process can't continue running. Therefore, there's no choice: the OS scheduler has to step in and select a different process.

In circumstances 2 and 3, the OS scheduler has a choice: it can either allow the current process to continue running, or it could step in and put the current process to sleep and select a different process to run. The latter operation is called "preempting" the current process and scheduling a new one to run.

So, yes, your understanding sounds about right.

$\endgroup$
  • $\begingroup$ Is that what's meant by "non-preemptive"? It sounds like the context is still that of preemptive multitasking. $\endgroup$ – ShadSterling Oct 6 '15 at 19:09
  • $\begingroup$ @Polyergic In a non-preemptive system, the process itself signals to the scheduler that it is ready to give up its allocated 'time-slice'. In a pre-emptive environment, processes are interrupted by the scheduler and the next process in the queue gets its turn (time-slice). In a pre-emptive system, scheduling is interrupt driven and is enforced by the scheduler; in a non-preemptive system, scheduling relies on the processes to voluntarily transfer control to the scheduler. Non-preemptive scheduling is often called run-to-completion. $\endgroup$ – NZD Nov 20 '15 at 6:11
  • $\begingroup$ @NZD: it would be better if the book said saomething like that. The definition it gives is confusing at best. $\endgroup$ – ShadSterling Nov 20 '15 at 16:08
4
$\begingroup$

yes, this is rather abstractly defined in your reference. for illustrative purpose lets take an example of what this means in practice. early mac programs say early 1990s and windows also were "non preemptive". what this means is that every program that wants to run, if it is going to allow other programs to run, must call an OS "wait" subroutine in its inner loops of every major operation that will "allow" other programs to run. the programs in a sense have to periodically "defer" to other programs explicitly in the program code. the operating system does not have the ability to interrupt the running program in nonpreemptive code. this is also sometimes called software multitasking because the multitasking is accomplished via software.

in a preemptive OS, which all major OSes are today, the hardware supports interrupting running processes, and the OS works in conjunction with the hardware to interrupt other processes that do not explcitly call a "wait" subroutine that returns control to the OS. clearly, nowadays nonpreemptive multitasking is now regarded as rather feeble and fragile, because it relies on programmers to explictly implement it in their code based on "best efforts", and fails if they dont. so theres an analogy to dynamic memory management: it works great in theory but in practice there are typically memory leaks on complex programs because humans cant code it perfectly.

so nonpreemptive multitasking is more of a historical/ theoretical concept these days which a programmer could apply in their own code, but serious operating systems all implement preemptive multitasking.

$\endgroup$
  • 1
    $\begingroup$ Non-preemptive scheduling is still widely used in small (real-time) applications where the overhead of preemptive task switching, the risk of race conditions and complexity of resource management (semaphores and blocking) are not justified with respect to the memory footprint and lack of processing power of the system. It is particularly well suited for event-driven systems. We've used it successfully in a large number of products. I'm talking about systems with around 64kB of ROM and 8kB of RAM. $\endgroup$ – NZD Nov 20 '15 at 20:39

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.