BOWEN UNIVERSITY, IWO

COLLEGE OF COMPUTING AND COMMUNICATION STUDIES

DEPARTMENT OF COMPUTER SCIENCE
CSC 322- OPERATING SYSTEM II
LECTURE NOTE 3

CPU SCHEDULING
CPU scheduling is the basis of multiprogrammed operating systems. By switching
the CPU among processes, the operating system can make the computer more
productive.

3.0 Basic Concepts

The idea of multiprogramming is relatively simple. A process is executed until it
must wait, typically for the completion of some I/O request. In a simple computer
system, the CPU would then just sit idle.

Scheduling is a fundamental operating system function. Almost all computer

resources are scheduled before use.

3.1 CPU-I/O Burst Cycle

The success of CPU scheduling depends on the following observed properties of
processes. Process execution consists of a cycle of CPU execution and I/O wait.
Processes alternate back and forth between these two states.

3.2 Context Switch

To give each process on a multi-programmed machine a fair share of the CPU, a
hardware clock generates interrupts periodically.

This allows the operating system to schedule all processes in the main memory
(using a scheduling algorithm) to run on the CPU at equal intervals. Each switch of
the CPU from one process to another is called a context switch.

3.3 Preemptive Scheduling

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, or invocation of wait for the termination of one of the child
processes).
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.

3.3.1 Dispatcher
• Switching context.
• Switching to user mode.
• Jumping to the proper location in the user program to restart that program
3.3.2 Scheduling Criteria
• Different CPU scheduling algorithms have different properties and may favour
one class of processes over another. In choosing which algorithm to use in a
particular situation, we must consider the properties of the various algorithms
Many criteria have been suggested for comparing CPU scheduling algorithms.
Criteria that are used include the following:
• CPU utilization.
• Throughput.
• Turnaround time.
• Waiting time.
• Response time.

3.4 Scheduling Algorithms

1. First-Come, First-Served Scheduling
2. Shortest-Job-First Scheduling
3. Priority Scheduling
4. Round-Robin Scheduling
5. Multilevel Queue Scheduling
6. Multilevel Feedback Queue Scheduling
 In a multilevel queue scheduling processes are permanenly assigned to one queues.
The processes are permanently assigned to one another, based on some propety of the
process, such as :
 Memory size
 Process priority
 Process type

Algorithm chooses the process from the occupied queue that has the highest priority,
and run that process either preemptively or non-preemptively.

3.5 Process Synchronization

A cooperating process is one that can affect or be affected by the other processes
executing in the system. Cooperating processes may either directly share a logical
address space (that is, both code and data), or be allowed to share data only through
files. The former case is achieved through the use of lightweight processes or threads.
Concurrent access to shared data may result in data inconsistency.

The concurrent processes executing in the operating system may be either

independent processes or
Cooperating processes. A process is independent if it cannot affect or be affected by
the other processes executing in the system. On the other hand, a process is
cooperating if it can affect or be affected by the other processes executing in the
system.

3.6 Inter-process Communication (IPC)

When Processes communicate with each other it is called “Inter – Process
Communication”. Process frequently needs to communicate, the output of the 1 st
process needs to pass to the 2nd one and so on to the other process.

Inter-process communication (IPC) is a set of methods for the exchange of data

among multiple threads in one or more processes. Processes may be running on one
or more computers connected by a network. IPC provides a mechanism to allow
processes to communicate and synchronize their actions without sharing the same
address space. IPC is particularly useful in a distributed environment, where the
communicating processes may reside on different computers connected to a network.
An example is a chat program used on the World Wide Web.

IPC methods are divided into methods for message passing, synchronization, shared
memory, and remote procedure calls (RPC). The method of IPC used may vary based
on the bandwidth and latency of communication between the threads, and the type of
data being communicated. There are several reasons for providing an environment
that allows process cooperation:

 Information sharing
 Computational speedup
 Modularity
 Convenience
 Privilege separation

IPC may also be referred to as inter-thread communication and inter-application

communication. IPC is best provided by a message-passing system. Message systems
can be defined in many different ways.

3.7 RACE CONDITION

We have a race condition if two processes or threads want to access the same item in
shared memory at the same time. It is where several processes access and manipulate
shared data concurrently. The final value of the shared data depends upon which
process finishes last. To prevent race conditions, concurrent processes must be
coordinated or synchronized. i.e. When several processes access and manipulate the
same data concurrently and the outcome of the execution depends on the particular
order in which the access takes place.

3.8 Mutual Exclusion

Sharable resources include processors, read-only files, and areas of memory protected
against modification. Non-sharable resources include most peripherals, read-write
files, areas of memory allocated to a process and its data. All shared resources/data
can be shared exclusively.

Formally, while one process executes the shared resources/variable, all other
processes desiring to do so at the same time/moment should be kept waiting; when
that process has finished executing the shared variable/resources, one of the processes
waiting to access the variable/resources should be allowed to proceed. In this fashion,
each process executing the shared data (variables) excludes all others from doing so
simultaneously.

Mutual Exclusion is a process by which each process access shared data exclusively.
It is also refers to the ability of multiple processes ( or threads) to share code,
resources, or data in such a way that only one process has access to the shared object
at a time.

Mutual exclusion needs to be enforced only when processes access shared modifiable
data - when processes are performing operations that do not conflict with one another
they should be allowed to proceed concurrently. When a process is accessing shared
modifiable data, the process is said to be in a Critical Section (Critical Region). It
must be ensured that when one process is in Critical Section, all other processes (at
least those that access the same shared modifiable data) are excluded from their own
critical sections.

While a process is in its CS, other processes may certainly continue executing outside
their Critical Sections. When a process leaves its Critical Section, then other process
waiting to enter its own Critical Section should be allowed to proceed( if indeed there
is a waiting process)
3.9 The Critical-Section Problem
The important feature of the system is that, when one process is executing in its
critical section, no other process is to be allowed to execute in its critical section.
Thus, the execution of critical sections by the processes is mutually exclusive in time.
The critical-section problem is to design a protocol that the processes can use to
cooperate. Each process must request permission to enter its critical
section.

A solution to the critical-section problem must satisfy the following three

requirements:
1. Mutual Exclusion: If process Pi is executing in its critical section, then no other
processes can be executing in their critical sections.
2. Progress: If no process is executing in its critical section and there exist some
processes that wish to enter their critical sections, then only those processes that are
not executing in their remainder section can participate in the decision of which will
enter its critical section next, and this selection cannot be postponed indefinitely.
3. Bounded Waiting: There exists a bound on the number of times that other
processes are allowed to enter their critical sections after a process has made a request
to enter its critical section and before that request is granted.

3.10 DEADLOCK
3.10.1 Definition of Deadlock
A process in a Multiprogramming system is said to be in a state of deadlock (or
deadlocked) if it is waiting for a particular event that will not occur. In this situation,
two or more processes cannot continue because the resource each process requires is
held by another.

A process requests resources; if the resources are not available at that time, the
process enters a wait state. It may happen that waiting processes will never again
change state, because the resources they have requested are held by other waiting
processes. This situation is called a deadlock.

In essence Deadlock can be defined as Deadlock can be defined as the permanent

blocking of a set of processes that either compete for system resources or
communicate with each other. The resources may be either physical or logical.
 Examples of physical resources are Printers, Tape Drivers, Memory Space, and CPU
Cycles. Examples of logical resources are Files, Semaphores, and Monitors.

3.10.2 Examples of Deadlock

1. If a process is given a task of waiting for an event to occur , and if the system
includes no provision for signaling that event, then we have one-process deadlock.
2. A traffic deadlock

1. A Simple Resource Deadlock

Most deadlock in Operating system develop because of the normal contention for
dedicated resources(resources that may be used by only one use at a time, sometimes
called serially reusable resources)

3.10.3 Resource Allocation Graph (RAG)

 The deadlock conditions can be modeled using a directed graph called a Resource
Allocation Graph (RAG). In some cases deadlocks can be understood more clearly
through the use of Resources Allocation Graph.
 2 kinds of nodes:
Boxes — represent resources( set of resource categories r1,r2,r3…….rN)
– Instances of the resource are represented as dots within the box
Circles — represent threads / processes ( set of proceses (p1,p2,p3…..pN)

 2 kinds of (directed) edges:

Request edge — from process to resource: indicates the process has requested the
resource, and is waiting to acquire it. i.e A set of directed arcs from pi to rj,
indicating that process pi has requested rj, and is currently waiting for that
resources to become available.

Assignment edge — from resource instance to process — indicates the process is

holding the resource instance. i.e A set of directed arcs from rj to pi indicating that
resource rj has been allocated to process pi, and that pi is currently holding
resource rj.

 When a request is made, a request edge is added

 When request is fulfilled, the request edge is transformed into an assignment edge
 When process releases the resource, the assignment edge is deleted

3.10.4 Indefinite Postponement

In any system that keeps processes waiting while it makes resource allocation/process
scheduling decisions. It is possible to delay indefinitely the scheduling of a process
while other processes receive the system’s attention. This situation is called by
various names including Indefinite Postponement, indefinite Blocking or Starvation.
It is can also be devastating as Deadlock.

3.10.5 Resources Concepts

A process must request a resource before using it, and must release the resource after
using it. A process may utilize a resource in only the below sequence.
3.11 Preemptable and Nonpreemptable Resources
Resources come in two flavors: preemptable and nonpreemptable. A preemptable
resource is one that can be taken away from the process with no ill effects. Memory is
an example of a preemptable resource and also CPU. On the other hand, a
nonpreemptable resource cannot be taken away from the process (without causing ill
effect). For example, CD resources are not preemptable at an arbitrary moment.
Reallocating resources can resolve deadlocks that involve preemptable resources.
Deadlocks that involve nonpreemptable resources are difficult to deal with. Files and
l I/O devices (printer) are non-preemptable resources.

3.12 Conditions Necessary for Deadlock

Coffman (1971) identified four (4) conditions that must hold simultaneously for
there to be a deadlock.
1. Mutual Exclusion Condition: When process claim exclusive control of
the resources they require i.e unsharable resources. The resources
involved are non-shareable. At least one resource (thread) must be
held in a non-shareable mode, that is, only one process at a time
claims exclusive control of the resource. If another process requests
that resource, the requesting process must be delayed until the
resource has been released.
2. Hold and Wait (Wait for Condition): Processes hold resources already
allocated to them while requesting or waiting for additional resources.
There must exist a process that is holding a resource already allocated
 to it while waiting for additional resource that are currently being held
by other processes.
3. No preemption Condition: Resources cannot be remove from the
processes holding them until the resources are used to completion or
released voluntarily by the process holding it.
4. Circular wait Condition: A circular chain of processes exists in which
each process holds one or more resources that are required by the next
process in the chain. The processes in the system form a circular list
or chain where each process in the list is waiting for a resource held
by the next process in the list.

3.13 Dealing with Deadlock

In general, there are four strategies of dealing with deadlock problem
1. Deadlock Prevention
2. Deadlock Avoidance
3. Deadlock Detection
4. Deadlock Recovery

3.13.1 Deadlock Prevention

This is to condition a system to remove any possibility of deadlock occurring i.e
ensure that the 4 condition necessary for deadlock does not occur.

Elimination of “Mutual Exclusion” Condition

The mutual exclusion condition must hold for non-sharable resources and not
required for sharable resources. That is, several processes cannot simultaneously
share a single resource. This condition is difficult to eliminate because some
resources, such as the tape drive and printer, are inherently non-shareable. Note that
shareable resources like read-only-file do not require mutually exclusive access and
thus cannot be involved in deadlock. For printer, avoid mutual exclusion through
spooling — then process won’t have to wait on physical printer.

Elimination of “Hold and Wait” Condition

There are two possibilities for elimination of the second condition. The first
alternative is that a process request be granted all of the resources it needs at once,
prior to execution. The second alternative is to disallow a process from requesting
resources whenever it has previously allocated resources. This strategy requires that
all of the resources a process will need must be requested at once. The system must
grant resources on “all or none” basis. If the complete set of resources needed by a
process is not currently available, then the process must wait until the complete set is
available. While the process waits, however, it may not hold any resources. It must
guarantee that whenever a process requests a resource, it does not hold any other
resources. Thus the “wait for” condition is denied and deadlocks simply cannot occur.
This strategy can lead to serious waste of resources.

For example, a program requiring ten tape drives must request and receive all ten
drives before it begins executing. If the program needs only one tape drive to begin
execution and then does not need the remaining tape drives for several hours. Then
substantial computer resources (9 tape drives) will sit idle for several hours. This
strategy can cause indefinite postponement (starvation). Since not all the required
resources may become available at once.

Elimination of “No-preemption” Condition

The non-preemption condition can be alleviated by forcing a process waiting for a
resource that cannot immediately be allocated to relinquish all of its currently held
resources, so that other processes may use them to finish. (If a process that is holding
some resources requests another resource that cannot be immediately allocated to it,
then all resources currently being held are released).

Suppose a system does allow processes to hold resources while requesting additional
resources. Consider what happens when a request cannot be satisfied. A process holds
resources a second process may need in order to proceed while second process may
hold the resources needed by the first process. This is a deadlock. This strategy
requires that when a process that is holding some resources is denied a request for
additional resources. The process must release its held resources and, if necessary,
request them again together with additional resources. Implementation of this strategy
denies the “no-preemptive” condition effectively
.
High Cost When a process releases resources the process may lose all its work to
that point. One serious consequence of this strategy is the possibility of indefinite
postponement (starvation). A process might be held off indefinitely as it repeatedly
requests and releases the same resources.
Elimination of “Circular Wait” Condition
The last condition, the circular wait, can be denied by imposing a total ordering on all
of the resource types and then forcing, all processes to request the resources in order
(increasing or decreasing). This strategy impose a total ordering of all resources
types, and to require that each process requests resources in a numerical order
(increasing or decreasing) of enumeration. With this rule, the resource allocation
graph can never have a cycle.

For example, provide a global numbering of all the resources, as shown

Card
1 ≡
reader
2 ≡ Printer
3 ≡ Plotter
4 ≡ Tape drive
Card
5 ≡
punch

Now the rule is this: processes can request resources whenever they want to, but all
requests must be made in numerical order. A process may request first printer and
then a tape drive (order: 2, 4), but it may not request first a plotter and then a printer
(order: 3, 2). The problem with this strategy is that it may be impossible to find an
ordering that satisfies everyone.
3.13.2 Deadlock Avoidance
This approach to the deadlock problem anticipates deadlock before it actually occurs.
This approach employs an algorithm to access the possibility that deadlock could
occur and acting accordingly. This method differs from deadlock prevention, which
guarantees that deadlock cannot occur by denying one of the necessary conditions of
deadlock.

If the necessary conditions for a deadlock are in place, it is still possible to avoid
deadlock by being careful when resources are allocated. Perhaps the most famous
deadlock avoidance algorithm, due to Dijkstra [1965], is the Banker’s algorithm, so
named because the process is analogous to that used by a banker in deciding if a loan
can be safely made.

3.13.3 Deadlock Detection

Deadlock detection is the process of actually determining that a deadlock exists and
identifying the processes and resources involved in the deadlock. The basic idea is to
check allocation against resource availability for all possible allocation sequences to
determine if the system is in deadlocked state. Of course, the deadlock detection
algorithm is only half of this strategy. They solve the problem of deadlock by
limiting access to resources and by imposing restrictions on processes. At the
opposite extreme, deadlock detection strategies do not limit resource access or restrict
process actions. With deadlock detection, requested resources are granted to
processes whenever possible. Once a deadlock is detected, there needs to be a way to
recover.

3.13.4 Deadlock Recovery

Once a deadlock is detected, there needs to be a way to recover several alternatives
exists. One possibility is to inform the operator that a deadlock has occurred, and to
let the operator deal with the deadlock manually. The other possibility is to let the
system recover from the deadlock automatically. There are two options for breaking a
deadlock. One solution is simply to terminate (abort) one or more processes to break
circular wait. The second option is to pre-empt some resources from one or more of
the deadlocked processes.
1. Terminate a process
 All deadlocked processes (Temporarily prevent resources from deadlocked
processes).
 One process at a time until no deadlock (Successively kill processes until the
system is deadlock free).
Aborting a process may not be easy. If the process was in the midst of updating a
file, terminating it will leave that file in an incorrect state. Similarly, if the process
was in the midst of printing data on the printer, the system must reset the printer to
a correct state before printing the next job.
There are many factors to determine which process to be terminated, these
factors include
- What the priority of the process is
- How long the process has computed , and how much longer the process will
compute before completing its designated task
- How many and what type of resources the process has used
- How many more resources the process needs in order to complete
- How many processes will need to be terminated
- Whether the process is interactive or batch

2. Preempt resources
To eliminate deadlocks using resource pre-emption, successfully pre-empt some
resources from processes and give these resources to other process until the
deadlock cycle is broken. If pre-emption is required to deal with deadlocks, then
three issues need to be addressed:
1. Selecting a victim: which resources and which processes are to be pre-
empted? As in process termination, determine the order of pre-emption to
minimize cost.
2. Rollback: If we pre-empt a resource from a process, we must roll back the
process to some safe state, and restart it from that state. Back off a process to some
check point allowing preemption of a needed resource and restarting the process at
the checkpoint later.
3. Starvation: Same process killed repeatedly. How do we ensure that
starvation will not occur? That is, how can we guarantee that resources will not
always be pre-empted from the same process? Don’t keep preempting same
process (i.e.,set some limit)
In a system where victim selection is based primarily on cost factors, it may
happen that the same process is always picked as a victim. As a result, this process
never completes its designated task, a starvation situation that needs to be dealt
with in any practical system. Clearly, we must ensure that a process can be picked
as a victim only a (small) finite number of times. The most common solution is to
include the number of rollbacks in the cost factor.