Chapter 2

Process Management
 Chapter Content

1. Introduction to process management

2. Process scheduling
3. Race Conditions
4. Deadlock Management.
5. Inter-process communication and
synchronization
 Introduction to Process
Management
• A process is an instance of an application execution.
– Application may be a program written by a user, or a
system application.
– Many instances of the same application may run at
the same time, or run by many different applications.
– Each running application is a process. The process
only exists for the duration of executing the
application.
• A program itself is a passive entity, whereas a process is
an active entity
 Process Management
• A process is a program in execution. It is a unit of work within the
system. Program is a passive entity, process is an active entity.
• Process needs resources to accomplish its task
– CPU, memory, I/O, files
– Initialization data
• Process termination requires reclaim of any reusable resources

• Single-threaded process has one program counter specifying

location of next instruction to execute
– Process executes instructions sequentially, one at a time, until completion
• Multi-threaded process has one program counter per thread
• Typically system has many processes, some user, some operating
system running concurrently on one or more CPUs
– Concurrency by multiplexing the CPUs among the processes / threads
 Process Management Activities
The operating system is responsible for the
following activities in connection with process
management:
• Creating and deleting both user and system
processes
• Suspending and resuming processes
• Providing mechanisms for process synchronization
• Providing mechanisms for process communication
• Providing mechanisms for deadlock handling
 Process Creation

Ways of creating a Process

• System initialization (Daemons)
• Execution of a process creation system
call by a running process
• A user request to create a process
• Initiation of a batch job
 Process Termination

• Normal exit (voluntary)

• Error exit (voluntary)
• Fatal error (involuntary)
• Killed by another process (involuntary)
 Process States
• Processes change state during their execution,
– sometimes by themselves (e.g. by making a system
call), and
– sometimes due to an external event (e.g. when the CPU
gets a timer interrupt).
• A process typically has three main states
– Running: when it is using the CPU
– Blocked: when it is unable to run until some external
event happens - waiting for I/O or another thread
– Ready to run: when it is temporarily stopped to let
another process run.
 Process States (cont)

•Processes are created in the ready state.

•A ready process may be scheduled to run by the operating system, and it
may be preempted and returned to the ready state.
•A process may also block waiting for an event, such as an I/O operation.
When the event occurs, the process becomes ready again. Such transitions
continue until the process terminates.
 Process Control Block (PCB)

• A data structure used by the operating system to implement processes

– Also called process table and has one entry per process
• Keep in mind that there is only one CPU and therefore only one set
of CPU registers
– These registers contain the values for the currently executing
process
• Each time a process is moved to the running state:
– Register values for the currently running process
are stored into its PCB
– Register values of the new running state are loaded
into the CPU
– This exchange of information is called a context switch
 PCB Contents
1. Process Identification
2. Process State – The state may be ready, blocked or running.
3. Program counter – The counter indicates the address of the next instruction to be
executed for this process.
4. CPU registers – The registers vary in number and type depending on the computer
architecture. They include accumulators, index registers, stack pointers and general-
purpose registers.
5. CPU scheduling information – This information includes a process priority, pointer to
scheduling queues and any other scheduling parameters.
6. Memory management information – This information includes the value of the base and
limit registers, page tables or segment tables depending on the memory system used by
the operating system.
7. Accounting information - This information includes the amount of CPU and real time
used, account numbers, time limits, process numbers and so on.
8. I/O status information – This information includes the list of all I/O devices allocated to
this process, list of open files etc
 Threads
• A process is defined sometime a heavyweight process;
a thread is defined as a lightweight process;
• Separate two ideas:
– Process: Ownership of memory, files, other
resources
– Thread: Unit of execution we use to dispatch
• Each thread has its own CPU state and stack, but they share the
rest of the address space and the environment.

• Multithreading
– Allow multiple threads per process
– An example of where multiple threads might be used is in a file
server process. It receives requests to read and write files and
send back the requested data or accepts updated data
 Benefits of Threads

• Takes less time to create a new thread than a

process
• Less time to terminate a thread than a process
• Less time to switch between two threads within
the same process
• Threads within the same process share memory
and files --> they can communicate without
invoking the kernel
 Some problems with threads
• A parent process may have multiple
threads which in turn creates more threads
– One thread may be blocked from a READ call
causing others to be blocked too
• When threads are sharing a data
structure, one of them may close a file
while another is reading the file
 Process Scheduling

• At any given time there are two processes that can be run
– OS must decide which one to run first
• Short-term scheduling - scheduling of processes that are ready to run and are loaded
into memory
• Dispatching - The action of loading the process state into the CPU.
• The part of the operating system that makes this decision is known as the scheduler
and the algorithm it uses is called the scheduling algorithm.
• The scheduler is usually concerned with deciding the policy and not the mechanism.
• There are various consideration when deciding a good scheduling algorithm. Some of
them include:
1. Fairness – making sure that each process gets its fair share of the CPU
2. Efficiency – keep the CPU busy 100% of the time
3. Response time – minimize response time for interactive users
4. Turnaround time – minimize the time batch users must wait for output
5. Throughput – maximize the number of jobs processed per unit time.
 Process Scheduling (cont)

• Nonpreemptive scheduling: occurs when the currently executing process gives up the CPU
voluntarily
• Preemptive scheduling: Preemption is the action of stopping a running job and scheduling
another in its place.
– Occurs when the operating system decides to favor another process, preempting the
currently executing process
– Once a job captures processor and begins execution, it remains in RUNNING state
uninterrupted.
– Until it issues an I/O request (natural wait) or until it is finished (exception for infinite loops).
• Context switching is required by all preemptive algorithms
– When Job A is preempted
• All of its processing information must be saved in its PCB for later (when Job A’s
execution is continued).
• Contents of Job B’s PCB are loaded into appropriate registers so it can start running
again (context switch).
– Later when Job A is once again assigned to processor another context switch is performed.
• Information from preempted job is stored in its PCB.
• Contents of Job A’s PCB are loaded into appropriate registers.
 Scheduling algorithms

• FCFS (First Come First Served)

• SRTN (Shortest Remaining Time Next)/ SJF
Shortest Job First
• Time slice (Round Robin)
• Priority based preemptive scheduling
• MLQ (Multiple Level Queue)
• MLQF (Multiple Level Queue with Feedback)
 First Come First Served
• Non-preemptive algorithm
• This scheduling strategy assigns priority to processes in the order in
which they request the processor
• Non-preemptive.
• Handles jobs according to their arrival time -- the earlier they arrive, the
sooner they’re served.
• Simple algorithm to implement -- uses a FIFO queue.
• Good for batch systems; not so good for interactive ones.
• Easy to implement
• it is not widely used, because the turn around time and the waiting
time for a given process are not predictable.
 FCFS example
i
τ(pi) 0 350 475 950 1200 1275 TTRnd(pi)
P0 P1 P2 P3 P4
0 350
1 125
2 475
3 250
4 75

• Average turn around time:

– TTRnd = (350 +475 +950 + 1200 + 1275)/5 = 850

• Average wait time:

– W = (0 + 350 +475 + 950 + 1200)/5 = 595
 Shortest Job First

• Non-preemptive.
• Handles jobs based on length of their CPU cycle time.
– Use lengths to schedule process with shortest time.
– Looks at all processes in the ready state and dispatches the one with
the smallest service time
• Optimal – gives minimum average waiting time for a given set of
processes.
– optimal only when all of jobs are available at same time and the CPU
estimates are available and accurate.
• Doesn’t work in interactive systems because users don’t
estimate in advance CPU time required to run their jobs
 SJF example
i
τ(pi) 0 75 200 450 800 1275
TTRnd(pi)
0 350 P4 P1 P3 P0 P2
1 125
2 475
3 250
4 75

• Average turn around time:

– TTRnd = (800 + 200 +1275 + 450 + 75)/5 = 560

• Average wait time:

– W = (450 + 75 +800 + 200 + 0)/5 = 305
 Time slice (Round Robin)
• Preemptive algorithm
• Each process gets a time slice of CPU time, distributing the
processing time equitably among all processes
requesting the processor
• Whenever the time slice expires, the control of the CPU is
given to the next process in the ready list; the process being
switched is placed back into the ready process list
• It is not well suited for long jobs, since the scheduler will
be called multiple times until the job is done
• It is very sensitive to the size of the time slice
– Too big – large delays in response time for interactive processes
– Too small – too much time spent running the scheduler
– Very big – turns into FCFS
 Time slice (Round Robin)
example
0 100 200 300 400 475 550 650
i
τ(pi) P0 P1 P2 P3 P4 P0 P1 P2 P3 P4 P0 P1 P2 P3

0 350
650 750 850 950 1050 1150 1250 1275
1 125 P0 P2 P3 P0 P2 P3 P0 P2 P0 P2 P2 P2 P2
2 475
3 250 Time slice size is 50, negligible amount of time for
4 75
context switching
• Average turn around time:
– TTRnd = (1100 + 550 + 1275 + 950 + 475)/5 = 870

• Average wait time:

– W = (0 + 50 + 100 + 150 + 200)/5 = 100

• The wait time shows the benefit of RR algorithm in the

terms of how quickly a process receives service
 RR scheduling with overhead
example
0 120 240 360 480 540 575 635 670 790
i
τ(pi) P0 P1 P2 P3 P4 P0 P1 P2 P3 P4 P0 P1 P2 P3

0 350 790 910 1030 1150 1270 1390 1510 1535

P0 P2 P3 P0 P2 P3 P0 P2 P0 P2 P2 P2 P2
1 125
2 475
3 250
Time slice size is 50, 10 units of time for context
4 75 switching

• Average turn around time:

– TTRnd = (1320 + 660 + 1535 + 1140 + 565)/5 =
1044
• Average wait time:
– W = (0 + 60 + 120 + 180 + 240)/5 = 120
 Priority based scheduling (Event
Driven)
• Both preemptive and non-preemptive variants
• Each process has an externally assigned priority
• Every time an event occurs, that generates process switch, the
process with the highest priority is chosen from the ready
process list
• There is the possibility that processes with low priority will
never gain CPU time
• There are variants with static and dynamic priorities; the
dynamic priority computation solves the problem with
processes that may never gain CPU time (the longer the
process waits, the higher its priority becomes)
• It is used for real time systems
 Priority based schedule example
i
τ(pi) Priority Highest priority corresponds to highest value
0 350 5
1 125 2
2 475 3 0 350 425 900 1025 1275
3 250 1 P0 P4 P2 P1 P3
4 75 4

• Average turn around time:

– TTRnd = (350 + 425 + 900 + 1025 + 1275)/5 = 795

• Average wait time:

– W = (0 + 350 + 425 + 900 + 1025)/5 = 540
 Shortest Remaining Time First (SRT)

• Preemptive version of the SJN algorithm.

• Processor allocated to job closest to completion.
– This job can be preempted if a newer job in READY
queue has a “time to completion” that's shorter.
• Can’t be implemented in interactive system -- requires
advance knowledge of CPU time required to finish
each job (which may not be known)
• SRT involves more overhead than SJN.
– OS monitors CPU time for all jobs in READY queue
and performs “context switching”.
 Multiple Level Queue scheduling
• Complex systems have requirements for real time,
interactive users and batch jobs, therefore a
combined scheduling mechanism should be used
• The processes are divided in classes
• Each class has a process queue, and it has
assigned a specific scheduling algorithm
• Each process queue is treated according to a queue
scheduling algorithm:
– Each queue has assigned a priority
– As long as there are processes in a higher priority queue,
those will be serviced
 MLQ example

priority
System processes queue ED Queue
and interrupts

Interactive processes RR Queue CPU

Batch processes FCFS Queue

• 2 queues
– Foreground processes (highest priority)
– Background processes (lowest priority)
• 3 queues
– OS processes and interrupts (highest priority, serviced ED)
– Interactive processes (medium priority, serviced RR)
– Batch jobs (lowest priority, serviced FCFS)
 Multiple Level Queue with
feedback
• Same with MLQ, but the processes could migrate from
class to class in a dynamic fashion
• Different strategies to modify the priority:
– Increase the priority for a given process during the compute
intensive paths (in the idea to that the user needs larger share of
the CPU to sustain acceptable service)
– Decrease the priority for a given process during the compute
intensive paths (in the idea that the user process is trying to get
more CPU share, which may impact on the other users)
– If a process is giving the CPU before its time slice expires, then the
process is assigned to a higher priority queue
• During the evolution to completion, a process may go
through a number of different classes
• Any of the previous algorithms may be used for treating a
specific process class.
 Practical example: BSD UNIX
scheduling
• MLQ with feedback approach – 32 run queues
– 0 through 7 for system processes
– 8 through 31 for processes executing in user space
• The dispatcher selects a process from the
queue with highest priority; within a queue, RR is
used, therefore only processes in highest priority
queue can execute; the time slice is less than
100us
• Each process has an external priority (used to
influence, but not solely determine the queue where
the process will be placed after creation)
 Problems with concurrent execution

• Concurrent processes (or threads) often

need to share data (maintained either in
shared memory or files) and resources
• If there is no controlled access to
shared data, some processes will
obtain an inconsistent view of this data
• The action performed by concurrent
processes will then depend on the order
in which their execution is interleaved
 Concurrency and Race
Conditions
• Processes working together may share
some common storage that each can read
and write.
– May be in main memory or a shared file.

• Race Conditions - When two or more

processes are reading or writing some
shared data and the final result depends
on who runs precisely when are called
race conditions.
 The critical section problem

• When a process executes code that

manipulates shared data (or resource), we say
that the process is in it’s critical section (CS)
(for that shared data)
• The execution of critical sections must be
mutually exclusive: at any time, only one
process is allowed to execute in its critical
section (even with multiple CPUs)
• Then each process must request the
permission to enter it’s critical section (CS)
 Synchronization

• Only one process may execute the

critical section of code
– Acquire exclusive rights
– Execute critical section
– Release exclusive rights
 Synchronization

• Semaphore – guards n resources

– Any thread can return a resource

• Mutual Exclusion (Mutex) – guards 1

resource
– Only the currently owning thread can
return the resource
• Threads block until the resource is granted
 Semaphores

• Counts the no. of available resources

• Acquire: decrement, Release: increment
• No allocation or identification of resources
• An atomically modifiable counter
• Race conditions over the semaphore are
prevented by
– virtual machine / pgm language interpreter
– operating system
– hardware
 Semaphores (cont)

• Semaphores: an integer combined with P

and V operations
– Call P to enter a critical section
• If semaphore value > 0, it is decremented
• If semaphore value == 0, wait
– Call V to exit a critical section
• Increments the value of the semaphore
• Waits up processes that are waiting
 Semaphore caveats

• Processes (i.e. programmers) must follow

the protocol and not:
– Forget to return a resource after use
– Return a resource that was not requested
– Hold a resource for too long
– Use a resource anyway
 Mutual Exclusion (Mutex)

• A binary semaphore (one resource)

• For mutual exclusions (mutex), semaphore
values are initialized to 1
• The process acquiring the resource is
the only one that can return it
(ownership)
 Monitors

• A mutex with a thread queue

• Threads queue for the mutex
• Threads can yield the resource (wait)
• Threads can alert other threads (notify)
 Monitors (cont)
• A monitor encapsulates some state, and provides methods
that operate on that state.
• In addition, it guarantees that these methods are executed in a
mutually exclusive manner.
– If a process tries to invoke a method from a specific monitor, and some
method of that monitor is already being executed by another process, the
first process is blocked until the monitor becomes available.

• Special case - when a process cannot complete the execution

of a method and has to wait for some event to occur
– It is then possible for the process to enqueue itself within the monitor,
and allow other processes to use it.
– Later, when the time is right, some other process using the monitor will
resume the enqueued process.
 Deadlocks

• Deadlock can be defined as the permanent blocking of a

set of processes that either compete for system resources
or communicate with each other.
• A common example is the traffic deadlock.
 The Conditions for Deadlock
• Three conditions of policy must be present for a deadlock to be possible:
1. Mutual exclusion. Only one process may use a resource at a
time. No process may access a resource unit that has been allocated to
another process.
2. Hold and wait. A process may hold allocated resources while
awaiting assignment of other resources.
3. No preemption. No resource can be forcibly removed from a
process holding it.
4. Circular wait. A closed chain of processes exists, such that
each process holds at least one resource needed by the next
process in the chain.
• The fourth condition is, actually, a potential consequence of the first three.
 Dealing with Deadlocks

1. Proactive Approaches:
– Deadlock Prevention
• Prevent one of the 4 necessary conditions from arising
• …. This will prevent deadlock from occurring
– Deadlock Avoidance
• Carefully allocate resources based on future knowledge
• Deadlocks are prevented

2. Ignore the problem

– Pretend deadlocks will never occur
– Ostrich approach… but surprisingly common!
 Deadlock Prevention
• Can the OS prevent deadlocks?
• Prevention: Negate one of necessary conditions
– Mutual exclusion:
• Make resources sharable
• Not always possible (printers?)
– Hold and wait
• Do not hold resources when waiting for another
 Request all resources before beginning execution
Processes do not know what all they will need
Starvation (if waiting on many popular resources)
Low utilization (Need resource only for a bit)
• Alternative: Release all resources before requesting anything new
– Still has the last two problems
 Deadlock Prevention

• Prevention: Negate one of necessary conditions

– No preemption:
• Make resources preemptable (2 approaches)
– Preempt requesting processes’ resources if all not available
– Preempt resources of waiting processes to satisfy request
• Good when easy to save and restore state of resource
– CPU registers, memory virtualization
– Circular wait: (2 approaches)
• Single lock for entire system? (Problems)
• Impose partial ordering on resources, request them in order
 Deadlock Prevention
• Prevention: Breaking circular wait
– Order resources (lock1, lock2, …)
– Acquire resources in strictly increasing/decreasing order
– When requests to multiple resources of same order:
• Make the request a single operation
– Intuition: Cycle requires an edge from low to high, and from high to low
numbered node, or to same node

1
1 2
2 4
1

3
Ordering not always possible, low resource utilization
 Deadlock Avoidance

• If we have future information

– Max resource requirement of each process before they execute

• Can we guarantee that deadlocks will never occur?

• Avoidance Approach:
– Before granting resource, check if state is safe
– If the state is safe  no deadlock!
 Deadlock Detection & Recovery
• If neither avoidance or prevention is implemented,
deadlocks can (and will) occur.
• Coping with this requires:
– Detection: finding out if deadlock has occurred
• Keep track of resource allocation (who has what)
• Keep track of pending requests (who is waiting for what)
– Recovery: untangle the mess.

• Expensive to detect, as well as recover

• Requires good algorithms
 Deadlock Detection Algorithms

• A check for deadlock can be made as frequently as

each resource request or, less frequently,
depending on how likely it is for a deadlock to
occur.
• Checking at each resource request has two
advantages: it leads to early detection, and the
algorithm is relatively simple because it is based on
incremental changes to the state of the system.
• On the other hand, such frequent checks consume
considerable processor time.
 Dining Philosophers’ Problem

• The dining philosophers problem was introduced by Dijkstra

• Five philosophers live in a house, where a table is laid for
them.
• The life of each philosopher consists
principally of thinking and eating,
and through years of thought, all of
the philosophers had agreed that the
only food that contributed to their
thinking efforts was spaghetti.
• Due to a lack of manual skill, each
philosopher requires two forks to eat
spaghetti.
 Dining Philosophers’ Problem (cont)

• The problem: devise a ritual (algorithm) that will

allow the philosophers to eat. The algorithm must
satisfy mutual exclusion (no two philosophers can
use the same fork at the same time) while avoiding
deadlock and starvation (in this case, the term has
literal as well as algorithmic meaning!).

• This problem may not seem important or relevant in

itself. However, it does illustrate basic problems in
deadlock and starvation.
 Other Issues

• Livelock
• Starvation
 Starvation

• Occurs when there is a priority based selection

process.
• If there are many high priority tasks (in a
continuous stream) and only one (or a few) low
priority tasks, the low priority tasks will never
be selected
• Starvation avoidance
– First-come, First-served
– Priority enhancement
 Interprocess Communication

• Processes within a system may be independent

or cooperating
• Cooperating processes need interprocess
communication (IPC)
• IPC - Mechanism for processes to communicate
and to synchronize their actions.
• Two models of IPC
– Shared memory
– Message passing
Communications Models
 Cooperating Processes

• Cooperating process can affect or be

affected by the execution of another
process
• Advantages of process cooperation
– Information sharing
– Computation speed-up
– Modularity
– Convenience
 Interprocess Communication – Message
Passing

• Mechanism for processes to communicate and

to synchronize their actions
• Message system – processes communicate with
each other without resorting to shared
variables
• IPC facility provides two operations:
– send(message) – message size fixed or variable
– receive(message)
• If P and Q wish to communicate, they need to:
– establish a communication link between them
– exchange messages via send/receive
 Direct Communication

• Processes must name each other explicitly:

– send (P, message) – send a message to process P
– receive(Q, message) – receive a message from
process Q
• Properties of communication link
– Links are established automatically
– A link is associated with exactly one pair of
communicating processes
– Between each pair there exists exactly one link
– The link may be unidirectional, but is usually bi-
directional
 Indirect Communication
• Messages are directed and received from
mailboxes (also referred to as ports)
– Each mailbox has a unique id
– Processes can communicate only if they share a
mailbox
• Properties of communication link
– Link established only if processes share a common
mailbox
– A link may be associated with many processes
– Each pair of processes may share several
communication links
– Link may be unidirectional or bi-directional
 Indirect Communication
• Operations
– create a new mailbox
– send and receive messages through mailbox
– destroy a mailbox
• Primitives are defined as:
send(A, message) – send a message to
mailbox A
receive(A, message) – receive a
message from mailbox A
 Synchronization

• Message passing may be either blocking or non-blocking

• Blocking is considered synchronous
– Blocking send has the sender block until the message is
received
– Blocking receive has the receiver block until a message is
available

• Non-blocking is considered asynchronous

– Non-blocking send has the sender send the message and
continue
– Non-blocking receive has the receiver receive a valid message
or null
 Communications in Client-Server Systems

• Sockets
• Remote Procedure Calls
• Remote Method Invocation (Java)
 Sockets
• A socket is defined as an endpoint
for communication
• Concatenation of IP address and
port
• The socket 161.25.19.8:1625 refers
to port 1625 on host 161.25.19.8
• Communication takes place between
a pair of sockets
Socket Communication
 Remote Procedure Calls

• Remote procedure call (RPC) abstracts

procedure calls between processes on
networked systems
• Stubs – client-side proxy for the actual
procedure on the server
• The client-side stub locates the server and
marshalls the parameters
• The server-side stub receives this message,
unpacks the marshalled parameters, and
peforms the procedure on the server
 Remote Method Invocation

• Remote Method Invocation (RMI) is a Java

mechanism similar to RPCs
• RMI allows a Java program on one machine to
invoke a method on a remote object
 Shared memory

• A portion of physical memory that is

shared by multiple processes.
Process A Process B

0x30000
0x50000 0x50000

Shared memory 0x70000

region
 Client/server with shared
memory

client Shared memory server

kernel
Output file Input file
 Shared memory

• Advantages
– good for sharing large amount of data
- very fast,
• Limitation
– no synchronization provided – applications must create
their own
• Alternative
- mmap system call, which maps file into the
address space of the caller,