Chapter 3: Processes

OS Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018

 Objectives
● To introduce the notion of a process
● To describe the various features of processes, including scheduling,
creation and termination, and communication
● To explore inter-process communication using shared memory and
message passing
● To describe communication in client-server systems

OS Concepts – 10th Edition 3.2 Silberschatz, Galvin and Gagne ©2018

 Process Concept

OS Concepts – 10th Edition 3.3 Silberschatz, Galvin and Gagne ©2018

 Process Concept
● Process
● A program in execution
● An active entity
● Requires resources (e.g., processor) to perform a function
● A single instance of an executable program
● Executes sequentially - (a single instruction is executed on behalf
of a process at a time)
● The terms “process” and “job” (or “task”) are used
interchangeably

● Processes can be described as either:

● I/O-bound process – spends more time doing I/O than
computations; many short CPU bursts
● CPU-bound process – spends more time doing computations;
few very long CPU bursts

OS Concepts – 10th Edition 3.4 Silberschatz, Galvin and Gagne ©2018

 Process Parts

● Multiple process parts:

● The program code, also called text section
● Current activity including program counter, and content of
processor’s registers
● Stack containing temporary data when invoking functions
4 Function parameters, return addresses, local variables
● Data section containing global variables
● Heap containing memory dynamically allocated during run time

OS Concepts – 10th Edition 3.5 Silberschatz, Galvin and Gagne ©2018

 Process in Memory

OS Concepts – 10th Edition 3.6 Silberschatz, Galvin and Gagne ©2018

 Process Concept (Cont.)
● Program is a passive entity stored on disk (executable file)
● Program becomes process (active entity) when executable file
loaded into memory

● Execution of program starts via GUI mouse clicks, command line

entry of its name, etc.

● One program can be several processes

● Consider multiple users executing the same program

OS Concepts – 10th Edition 3.7 Silberschatz, Galvin and Gagne ©2018

 Process State

● As a process executes, it changes state

● new: The process is being created
● ready: The process is waiting to be assigned to a processor
● running: Instructions are being executed
● waiting: The process is waiting for some event to occur
● terminated: The process has finished execution

OS Concepts – 10th Edition 3.8 Silberschatz, Galvin and Gagne ©2018

 Diagram of Process State

OS Concepts – 10th Edition 3.9 Silberschatz, Galvin and Gagne ©2018

 Process Control Block (PCB)
Each process is represented in OS by a data
structure called a PCB (also called task
control block)
● Process state – running, waiting, etc.
● Program counter – location of instruction
to next execute
● CPU registers – contents of all
process-centric registers
● CPU scheduling information- priorities,
scheduling queue pointers
● Memory-management information –
memory allocated to the process
● Accounting information – CPU used, clock
time elapsed since start, time limits
● I/O status information – I/O devices
allocated to process, list of open files

OS Concepts – 10th Edition 3.10 Silberschatz, Galvin and Gagne ©2018

 Process Scheduling

OS Concepts – 10th Edition 3.11 Silberschatz, Galvin and Gagne ©2018

 Process Scheduling

● Maximize CPU use, quickly switch processes onto CPU for time
sharing

● Process scheduler selects among available processes for next

execution on CPU

● Maintains scheduling queues of processes

● Job queue – set of all processes in the system
● Ready queue – set of all processes residing in main memory,
ready and waiting to execute
● Device queues – set of processes waiting for an I/O device

OS Concepts – 10th Edition 3.12 Silberschatz, Galvin and Gagne ©2018

 Ready Queue & I/O Device Queues

OS Concepts – 10th Edition 3.13 Silberschatz, Galvin and Gagne ©2018

 Representation of Scheduling

Queueing diagram represents queues, resources, flows

OS Concepts – 10th Edition 3.14 Silberschatz, Galvin and Gagne ©2018

 Schedulers
● Long-term scheduler (or job scheduler) – selects which
processes in the job queue should be brought into the ready queue
● The first manager that the job encounters
● Invoked infrequently (seconds, minutes) ⇒ (may be slow)

● Short-term scheduler (or CPU scheduler) – selects which

process in the ready queue should be executed next and allocates
CPU, and when it should be terminated
● Sometimes the only scheduler in a system
● Invoked frequently (milliseconds) ⇒ (must be fast)

● Medium-term scheduler can be added if degree of multiple

programming needs to decrease (or when the system is overloaded)
● Used in a highly interactive systems
● Remove process from memory, store on disk, bring back in
from disk to continue execution: swapping

OS Concepts – 10th Edition 3.15 Silberschatz, Galvin and Gagne ©2018

 3
1 run 6
rea term
new nin inat.
dy
g
2

5 4

wai
⚫ 1 = some predefined policy
ting

⚫ 2 = some predefined algorithm

⚫ 3 = time interrupt or priority interrupt

■ 1 = job scheduler
⚫ 4 = initiated by an I/O or page request
■ 2,3,4,5 = process scheduler instructions

⚫ 5 = initiated by a signal from the I/O device

■ 6 = process scheduler (or job manager, or the page fault handler
scheduler)
⚫ 6 = termination (including releasing resources)
could be either natural or by force

OS Concepts – 10th Edition 3.16 Silberschatz, Galvin and Gagne ©2018

 Context Switch
● When CPU switches to another process, the system must save the
state of the old process and load the saved state for the new
process via a context switch

● Context of a process represented in the PCB

● Context-switch time is overhead; the system does no useful work

while switching
● The more complex the OS and the PCB, the longer the context
switch (the more work must be done during a context switch)

OS Concepts – 10th Edition 3.17 Silberschatz, Galvin and Gagne ©2018

 CPU Switching Processes

OS Concepts – 10th Edition 3.18 Silberschatz, Galvin and Gagne ©2018

 Context Switch

CPU
P1 sche P2
duler
Inter
Runn rupt Save state P1 Read
ing y
Select P2
Restore state
P2

Read Runn
y ing
Inter
rupt

Save state P2

Select P1
Restore state
Runn Read
P1
ing y

OS Concepts – 10th Edition 3.19 Silberschatz, Galvin and Gagne ©2018

 Operations on Processes

OS Concepts – 10th Edition 3.20 Silberschatz, Galvin and Gagne ©2018

 Operations on Processes

● System must provide mechanisms for:

● Process creation
● Process termination
● …

OS Concepts – 10th Edition 3.21 Silberschatz, Galvin and Gagne ©2018

 Process Creation

● Parent process creates children processes, which, in turn create

other processes, forming a tree of processes

● Generally, process identified and managed via a process identifier

(pid)

● Resource sharing options

● Parent and children share all resources
● Children share subset of parent’s resources
● Parent and child share no resources

● Execution options
● Parent and children execute concurrently (e.g., Web Server)
● Parent waits until children terminate (e.g., Batch Processing)

OS Concepts – 10th Edition 3.22 Silberschatz, Galvin and Gagne ©2018

 A Tree of Processes in Linux

OS Concepts – 10th Edition 3.23 Silberschatz, Galvin and Gagne ©2018

 Process Creation (Cont.)
● Address space (two possibilities)
● Child duplicate of parent (has the same program); e.g.,
Notepad++
● Child has a program loaded into it; e.g., Web Server (parent) and
child process handling database interactions

● UNIX examples
● fork() system call creates new process
● exec() system call used after a fork() to replace the process’
memory space with a new program

OS Concepts – 10th Edition 3.24 Silberschatz, Galvin and Gagne ©2018

 Process Termination

● Process executes last statement and then asks the OS to delete it

using the exit() system call.
● Returns status data from child to parent (via wait())
● Process’resources are deallocated by OS

● Parent may terminate the execution of children processes using the

abort() system call. Some reasons for doing so:
● Child has exceeded allocated resources
● Task assigned to child is no longer required
● The parent is exiting, and the OS does not allow a child to
continue if its parent terminates

OS Concepts – 10th Edition 3.25 Silberschatz, Galvin and Gagne ©2018

 Process Termination (Cont.)

● Some OS’s do not allow child to exists if its parent has terminated. If
a process terminates, then all its children must also be terminated.
● Cascading termination: All children, grandchildren, etc. are
terminated.
● The termination is initiated by the OS

● The parent process may wait for termination of a child process by

using the wait()system call. The call returns status information
and the pid of the terminated process
pid = wait(&status);

● If no parent waiting (did not invoke wait() yet), terminated

process is called a zombie

● If parent terminated without invoking wait(), process is an orphan

OS Concepts – 10th Edition 3.26 Silberschatz, Galvin and Gagne ©2018

 Chrome Browser

● Many web browsers ran as a single process (some still do)

● If one website causes trouble, entire browser can hang or crash

● Google Chrome is a multi-process browser with 3 different types of

processes:
● Browser process manages user interface, disk and network I/O
● Renderer process renders web pages, deals with HTML,
Javascript. A new renderer created for each website opened
4 Runs in sandbox restricting disk and network I/O, minimizing
effect of security exploits
● Plug-in process for each type of plug-in

OS Concepts – 10th Edition 3.27 Silberschatz, Galvin and Gagne ©2018

 Chapter 3: Processes

OS Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018

 Inter-process Communication

OS Concepts – 10th Edition 3.29 Silberschatz, Galvin and Gagne ©2018

 Inter-process Communication (IPC)
● Processes within a system may be independent or cooperating
● Cooperating process can affect or be affected by other processes,
including sharing data
● Reasons for cooperating processes:
● Information sharing
● Computation speedup
● Modularity
● Convenience
● Cooperating processes need interprocess communication (IPC)
● Two models of IPC
● Shared memory
● Message passing

OS Concepts – 10th Edition 3.30 Silberschatz, Galvin and Gagne ©2018

 Communications Models
(a) Message passing. (b) shared memory.

OS Concepts – 10th Edition 3.31 Silberschatz, Galvin and Gagne ©2018

 Producer-Consumer Problem

● Paradigm for cooperating processes, producer process produces

information that is consumed by a consumer process
● unbounded-buffer places no practical limit on the size of the
buffer
● bounded-buffer assumes that there is a fixed buffer size

OS Concepts – 10th Edition 3.32 Silberschatz, Galvin and Gagne ©2018

 IPC – Shared Memory

● An area of memory is shared among the processes that wish to

communicate

● The communication is under the control of the users processes not

the OS

● Major issues is to provide mechanism that will allow the user

processes to synchronize their actions when they access shared
memory

● Synchronization is discussed in great details in Chapter 6

OS Concepts – 10th Edition 3.33 Silberschatz, Galvin and Gagne ©2018

 IPC – 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)
● receive(message)

● The message size is either fixed or variable

● Examples include sockets, pipes, message queues, and remote

procedure calls (RPC)

OS Concepts – 10th Edition 3.34 Silberschatz, Galvin and Gagne ©2018

 IPC – Message Passing (Cont.)

● If processes P and Q wish to communicate, they need to:

● Establish a communication link between them
● Exchange messages via send/receive

● Implementation issues:
● How are links established?
● Can a link be associated with more than two processes?
● How many links can there be between every pair of
communicating processes?
● What is the capacity of a link?
● Is the size of a message that the link can accommodate fixed or
variable?
● Is a link unidirectional or bi-directional?

OS Concepts – 10th Edition 3.35 Silberschatz, Galvin and Gagne ©2018

 IPC – Message Passing (Cont.)
● Implementation of communication link

● Physical:
4 Shared memory
4 Hardware bus
4 Network

● Logical:
4 Direct or indirect
4 Synchronous or asynchronous
4 Automatic or explicit buffering

OS Concepts – 10th Edition 3.36 Silberschatz, Galvin and Gagne ©2018

 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

OS Concepts – 10th Edition 3.37 Silberschatz, Galvin and Gagne ©2018

 Indirect Communication

● Messages are directed and received via 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

OS Concepts – 10th Edition 3.38 Silberschatz, Galvin and Gagne ©2018

 Indirect Communication (Cont.)
● Operations
● create a new mailbox (port)
● 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

OS Concepts – 10th Edition 3.39 Silberschatz, Galvin and Gagne ©2018

 Indirect Communication (Cont.)
● Mailbox sharing
● P1, P2, and P3 share mailbox A
● P1, sends; P2 and P3 receive
● Who gets the message?

● Solutions
● Allow a link to be associated with at most two processes
● Allow only one process at a time to execute a receive operation
● Allow the system to select arbitrarily the receiver. Sender is
notified who the receiver was.

OS Concepts – 10th Edition 3.40 Silberschatz, Galvin and Gagne ©2018

 Synchronization
● Message passing may be either blocking or non-blocking

● Blocking is considered synchronous

● Blocking send -- the sender is blocked until the message is
received
● Blocking receive -- the receiver is blocked until a message is
available

● Non-blocking is considered asynchronous

● Non-blocking send -- the sender sends the message and
continue
● Non-blocking receive -- the receiver receives a valid message or
null message

● Different combinations possible

● If both send and receive are blocking, we have a rendezvous

OS Concepts – 10th Edition 3.41 Silberschatz, Galvin and Gagne ©2018

 Buffering

● Queue of messages attached to the link.

● Implemented in one of three ways

1. Zero capacity – no messages are queued on a link.

Sender must wait for receiver (rendezvous)

2. Bounded capacity – finite length of n messages

Sender must wait if the link is full

3. Unbounded capacity – infinite length

Sender never waits

OS Concepts – 10th Edition 3.42 Silberschatz, Galvin and Gagne ©2018

 Communications in Client-Server
Systems

OS Concepts – 10th Edition 3.43 Silberschatz, Galvin and Gagne ©2018

 Communications in C/S Systems

● Sockets
● Remote Procedure Calls (RPC)
● Pipes

OS Concepts – 10th Edition 3.44 Silberschatz, Galvin and Gagne ©2018

 Sockets
● A socket is defined as an endpoint for communication

● Concatenation of IP address and port – a number included at start of

message packet to differentiate network services on a host

● The socket 161.25.19.8:1625 refers to port 1625 on host 161.25.19.8

● Communication is between a pair of sockets

● All ports below 1024 are well known, used for standard services

● Special IP address 127.0.0.1 (loopback) to refer to system on which

process is running

OS Concepts – 10th Edition 3.45 Silberschatz, Galvin and Gagne ©2018

 Socket Communication

OS Concepts – 10th Edition 3.46 Silberschatz, Galvin and Gagne ©2018

 Remote Procedure Calls (RPC)
● Remote procedure call (RPC) abstracts procedure calls between
processes on networked systems
● Again, uses ports for service differentiation

● 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 performs the procedure on the server

● On Windows, stub code compile from specification written in

Microsoft Interface Definition Language (MIDL)

OS Concepts – 10th Edition 3.47 Silberschatz, Galvin and Gagne ©2018

 Remote Procedure Calls (RPC)

OS Concepts – 10th Edition 3.48 Silberschatz, Galvin and Gagne ©2018

 Pipes
● Acts as a conduit (or channel) allowing two processes to
communicate

● Issues:
● Is communication unidirectional or bidirectional?
● In the case of two-way communication, is it half or full-duplex?
● Must there exist a relationship (i.e., parent-child) between the
communicating processes?
● Can the pipes be used over a network?

● Ordinary pipes – cannot be accessed from outside the process that

created it. Typically, a parent process creates a pipe and uses it to
communicate with a child process that it created.

● Named pipes – can be accessed without a parent-child relationship.

OS Concepts – 10th Edition 3.49 Silberschatz, Galvin and Gagne ©2018

 Pipes (Unix Examples)
● Ordinary pipes

$ ls | grep “examples”

● Named (or fifo) pipes

$ mkfifo named_pipe_example
$ cat named_pipe_example

$ echo "Message from T2" > named_pipe_example

OS Concepts – 10th Edition 3.50 Silberschatz, Galvin and Gagne ©2018

 End of Chapter 3

OS Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018