Difficulty understanding pre-emptive vs non-preemptive CPU scheduling

Question

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.

Answer 1

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.

Answer 2

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.