CPU Scheduling

When the CPU becomes available, as a result of
the CPU scheduler has the responsibility of deciding which process (or thread) gets to use the CPU next.

Considerations:

1.  The CPU-I/O burst cycle

Programs tend to alternate between periods of CPU activity and I/O activity

I/O bound processes have short CPU bursts.  CPU processes have long CPU bursts.

2.  Preemptive vs. nonpreemptive scheduling

In preemptive scheduling, a process may lose control of the CPU due to
Preemption prevents one process from getting too much CPU time.  But -- it results in more overhead from context switching and more synchronization problems in accessing shared data.

Goals of a scheduling policy:


Some scheduling policies

1.  FCFS (First come, first served)

Nonpreemptive

Problem:  One CPU-bound process can hold the CPU indefinitely.  The "convoy effect"  --  Many I/O bound processes may get stuck behind a single CPU-bound process.

2.  Round robin
Q:  How to set the quantum?

too high -- degenerates to FCFS
too low -- too much overhead in context switches

Rule of thumb:  Choose quantum so that most of the time, a process gives up the CPU voluntarily; i.e., before the end of its quantum.

3.  Shortest Job First (SJF)

Estimate the length of the next CPU burst for each process.  (How?)  Then schedule processes in increasing order.

Advantage:
Disadvantages:
May be preemptive or nonpreemptive.  The preemptive version is called SRTF (Shortest Remaining Time First).


Aside:  Gantt charts can be used to illustrate scheduling behavior.

Suppose that a system has three processes, with the following table of arrival times and burst times:

process number
arrival time
burst time
1
0
6
2
0
10
3
2
2

A Gantt chart shows a timeline of CPU usage, as follows:

4.  Priority scheduling

(HPF -- Highest Priority First)

Issues:

5.  Multilevel queue
6.  Multilevel feedback queues

Dynamic prioritization based on CPU burst characteristics
CPU bound ==> lower priority, longer time slice
I/O bound ==> higher priority, shorter time slice

Multiprocessor scheduling

A multiprocessor is a computer with more than one identical CPU and a shared memory.

The scheduling problem for multiprocessors can be viewed as the problem of matching processes to processors.

Goal:  Share the workload among all the processors.

Design issues:
Most modern operating systems use symmetric multiprocessing with private ready queues.

Multiprocessor scheduling may also depend on the hardware architecture

Thread scheduling

If the operating system supports kernel threads, then threads are the basic unit of scheduling.

many-to-one model  (many user threads are mapped onto one process or kernel thread.)  The process, as viewed by the kernel, is a single scheduling unit and competes with other processes for CPU time.  The kernel is unaware of the user threads, so it doesn't make any scheduling decisions for them.  The user thread library has its own scheduler that determines which thread to run when the process has use of the CPU.

one-to-one model  (one kernel thread per user thread)  Each user thread is mapped onto a kernel thread.  The kernel is responsible for scheduling the kernel threads, so it effectively schedules the user threads at the same time.  The user library code does not need to take any responsibility for scheduling.

many-to-many model  (several user threads are mapped onto several kernel threads)  The kernel schedules the kernel threads.  The user thread library needs a scheduler whose responsibility it is to map the user threads onto the kernel threads.  So we have two levels of scheduling.  For example, if the running user thread exits, the exit routine calls the user-level scheduler, which finds an unbound user thread and transfers control to it.  The old thread, the new thread, and the user-level scheduler all run on the same kernel thread.

Q:  Should the kernel-level scheduler take into account which process each thread belongs to when making scheduling decisions?

Pthread contention scope

The Pthread library supports the notion of contention scope, which may be either process (PCS) or system (SCS).  The term indicates whether, in competing for CPU time, a thread competes with all other threads on the system or just those owned by the same process.

Examples

Solaris
Linux