The process state transition diagram shown below is representative of:

A scheduler is called preemptive if the operating system can force a RUNNING process out of the CPU and send it back to READY before that process itself chooses to give up the CPU, for example when its time slice expires or a higher-priority process arrives. A non-preemptive scheduler never does this: once a process starts running, it keeps the CPU until it voluntarily blocks for I/O or terminates. In a process-state transition diagram, this distinction shows up as one tell-tale edge: a direct RUNNING to READY transition. That edge can exist only if the OS is allowed to interrupt a still-runnable process, so its presence, on top of the usual READY to RUNNING dispatch edge, is what marks a preemptive scheduler.

In the given diagram, RUNNING and READY are joined by two separate arrows: READY to RUNNING, the normal dispatch when the scheduler picks a waiting process to run, and RUNNING to READY, the process being sent back to the queue while it is still able to run. Applying the concept above, this second edge is exactly the signature of preemption, so the diagram represents an operating system with a preemptive scheduler.

Checking this against each of the other options confirms none of them fit the same diagram feature:

• a batch operating system: a batch system runs submitted jobs to completion (or until they need I/O) without any mechanism to reclaim the CPU purely to switch jobs, so it has no need for a RUNNING to READY edge at all.

• an operating system with a non-preemptive scheduler: by definition, this model only lets a process leave RUNNING when it blocks or terminates on its own; it has no path back to READY while the process is still runnable, which contradicts the diagram.

• a uni-programmed operating system: with only one process in the system, there is no other process to hand the CPU to, so a distinct RUNNING to READY hand-off, which implies competition for the CPU, does not fit this model either.

Note: the arrow near the BLOCKED state in this figure has been reported as pointing the wrong way; it should run from BLOCKED to READY when an I/O or event completes, not the reverse. That drawing issue does not change the answer here. The RUNNING and READY pair is the only edge that decides preemptive versus non-preemptive scheduling, and it is drawn correctly.