Operating Systems

Chapter 3
Dr. Sohail Abbas
 Chapter 3: Processes

Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne

 Chapter 3: Processes
 Process Concept
 Process Scheduling
 Operations on Processes
 Interprocess Communication
 Examples of IPC Systems
 Communication in Client-Server Systems

1501-352 Operating Systems 1.3

 Some terms to differentiate
 Uniprogramming: RAM=> single process
 Multiprogramming: RAM => multiple processes
 Multitasking: RAM => multiple processes belonging to
different users
 Multiprocessing: multiple CPUs/ microprocessors
 Multithreading: multiple threads inside a process.

1501-352 Operating Systems 1.4

 Process Concept
 An operating system executes a variety of programs:
 Batch system – jobs
 Time-shared systems – user programs or tasks
 Textbook uses the terms job and process almost
interchangeably
 Process – a program in execution; process execution must
progress in sequential fashion
 Program is passive entity stored on disk (executable file),
process is active
 Program becomes process when executable file loaded into
memory
 Execution of program started via GUI mouse clicks, command
line entry of its name, etc
 One program can be several processes
 Consider multiple users executing the same program

1501-352 Operating Systems 1.5

 Process Concept

 Multiple parts:
 The program code, also called text
section. Also includes current
activity including program counter,
processor registers
 Stack containing temporary data
 Function parameters, return
addresses, local variables
 Data section containing global
variables
 Heap containing memory
dynamically allocated during run
time

1501-352 Operating Systems 1.6

Memory Layout of a C Program

1501-352 Operating Systems 1.7

 Process State: Hospital Analogy

Interrupt: time expired

admitted exit
New Waiting hall Dr. Checkup Terminated
dispatch

Tests completion Tests prescribed

Laboratory

1501-352 Operating Systems 1.8

 Process State
 As a process executes, it changes state
 new: The process is being created
 running: Instructions are being executed
 waiting: The process is waiting for some event to occur
 ready: The process is waiting to be assigned to a processor
 terminated: The process has finished execution

1501-352 Operating Systems 1.9

 Process Control Block (PCB)
Information associated with each process, aka
task control block
 Process state – running, waiting, etc
 Process identification (number)
 Program counter – location of instruction to
next execute
 CPU registers – contents of 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

1501-352 Operating Systems 1.10

 Process Representation in Linux
 Represented by the C structure task_struct
pid t_pid; /* process identifier */
long state; /* state of the process */
unsigned int time_slice /* scheduling information */
struct task_struct *parent; /* this process’s parent */
struct list_head children; /* this process’s children */
struct files_struct *files; /* list of open files */
struct mm_struct *mm; /* address space of this process */

1501-352 Operating Systems 1.11

 Process Scheduling
 Maximize CPU use, quickly switch processes onto CPU for time
sharing
 Process scheduler selects among available processes for next
execution on CPU
 For a single-processor system, If there are more processes, the
rest will have to wait until the CPU is free and can be
rescheduled.
 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
 Processes migrate among the various queues

1501-352 Operating Systems 1.12

Ready Queue And Various
I/O Device Queues

1501-352 Operating Systems 1.13

 Representation of Process Scheduling

 Queueing diagram represents queues, resources,

flows

1501-352 Operating Systems 1.14

 Schedulers
 Long-term scheduler (or job scheduler) – selects which
processes should be brought into the ready queue
 Short-term scheduler (or CPU scheduler) – selects which
process should be executed next and allocates CPU
 Sometimes the only scheduler in a system
 Short-term scheduler is invoked very frequently (milliseconds)
 (must be fast)

 Long-term scheduler is invoked very infrequently (seconds,

minutes)  (may be slow)

 The long-term scheduler controls the degree of

multiprogramming

 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
1501-352 Operating Systems 1.15
 Schedulers
 Long-term scheduler strives for good process mix because
 If all processes are I/O bound, the ready queue will almost
always be empty, and the short-term scheduler will have little
to do.
 If all processes are CPU bound, the I/O waiting queue will
almost always be empty, devices will go unused, and again the
system will be unbalanced.
 The system with the best performance will thus have a
combination of CPU-bound and I/O-bound processes.

 Time-sharing systems such as UNIX and Microsoft Windows

systems often have no long-term scheduler.
 If performance declines to unacceptable levels on a multiuser
system, some users will simply quit.

1501-352 Operating Systems 1.16

 Addition of Medium-Term Scheduling
 Medium-term scheduler can be added if degree of
multiprogramming needs to decrease (ex. Removing a process
from memory to reduce active contention for the CPU)
 Remove process from memory, store on disk, bring back in
from disk to continue execution: swapping

1501-352 Operating Systems 1.17

 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 -> longer the context
switch

 Time dependent on hardware support

 Some hardware provides multiple sets of registers per CPU -
> multiple contexts loaded at once

1501-352 Operating Systems 1.18

CPU Switch From Process to Process

1501-352 Operating Systems 1.19

 Operations on Processes
 System must provide mechanisms for process creation,
termination, and so on as detailed next

1501-352 Operating Systems 1.20

 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
 Parent waits until children terminate

1501-352 Operating Systems 1.21

A Tree of Processes in Linux

1501-352 Operating Systems 1.22

 Process Creation (Cont.)
 Address space
 Child duplicate of parent
 Child has a separate program loaded into it

 UNIX examples
 fork() system call creates new process
 the return code for the fork() is zero for the new (child)
process, whereas the (nonzero) process identifier of the
child is returned to the parent.
 exec() system call used after a fork() to replace the
process’ memory space with a new program
 When the exec()is not called: the parent and child are
concurrent processes running the same code, each process
has its own copy of data.
 Parent process can issue a wait() to move itself off the
ready queue until the termination of the child.

1501-352 Operating Systems 1.23

Process Creation (Cont.)

1501-352 Operating Systems 1.24

Process creation

Parent ID= 101

Child ID = 150

Fork => non-zero => parent

Fork => zero => child

Try these on YouTube.

How to create the following

in Ubuntu

1. A process
2. Zombie process
3. Orphan process

1501-352 Operating Systems 1.25

 Process Termination
 Process executes last statement and asks the operating
system to delete it (exit())
 Output data from child to parent (via wait())
 Process’ resources are deallocated by operating system
 Parent may terminate execution of children processes (abort())
for various reasons, such as
 Child has exceeded allocated resources
 Task assigned to child is no longer required
 If parent is exiting (such as session leader, i.e. terminal)
 Some operating systems do not allow child to continue if
its parent terminates
– All children terminated - cascading termination

1501-352 Operating Systems 1.26

 Process Termination
 If no parent waiting, then terminated process is a zombie
 If parent terminated or crashed (without explicitly killing or
aborting the children), processes are orphans, The init or
systemd process will become the new parent of the orphans
(UNIX)
 In modern Linux systems, an orphan process may be handed
over to a "subreaper" process instead of init.

1501-352 Operating Systems 1.27

Review Forking

1501-352 Operating Systems 1.28

Zombie process

1501-352 Operating Systems 1.29

Orphan process

1501-352 Operating Systems 1.30

 Interprocess Communication
 Processes within a system may be independent or cooperating
 A process is independent if it cannot affect or be affected by
the other processes executing in the system.
 Cooperating process can affect or be affected by other
processes
 Any process that does not share data with any other
process is independent; otherwise, (when share data, then)
cooperative.

 Reasons for cooperating processes:

 Information sharing
 Computation speedup
 Modularity

1501-352 Operating Systems 1.31

 Interprocess Communication
 Cooperating processes need interprocess communication (IPC)
 Two models of IPC
 Shared memory
 A region of memory that is shared by cooperating
processes is established.
 Processes can then exchange information by reading and
writing data to the shared region.
 1. Hard to implement, (difficult to setup)
 2. Faster (system calls are required only to establish
shared-memory regions),
 3. Used for larger data (on same system)

1501-352 Operating Systems 1.32

 Interprocess Communication
 Message passing
 Communication takes place by means of messages
exchanged between the cooperating processes
 1. Easy to implement,
 2. Slower (use of system calls for message transfers: kernel
intervention),
 3. Used for smaller data (across multiple systems)

 For systems with several processing cores message passing

provides better performance than shared memory.
 Shared memory suffers from cache coherency issues

1501-352 Operating Systems 1.33

Communications Models

1501-352 Operating Systems 1.34

 Shared Memory
 Typically, a shared-memory region resides in the address space
of the process creating the shared-memory segment.

 Other processes that wish to communicate using this shared-

memory segment must attach it to their address space.

 The form of the data and the location are determined by these
processes and are not under the operating system’s control.

 The processes are also responsible for ensuring that they are
not writing to the same location simultaneously.

1501-352 Operating Systems 1.35

 Shared Memory
 Paradigm for cooperating processes is producer-consumer model,
 producer process produces information that is consumed by a
consumer process
 For example, a compiler may produce assembly code that is
consumed by an assembler. The assembler, in turn, may
produce object modules that are consumed by the loader.
 Real world example: Notice board (online version: BlackBoard)
 One solution to the producer–consumer problem uses shared
memory.

 To run these processes concurrently, a buffer is needed that can

be filled by the producer and emptied by the consumer.
 unbounded-buffer places no practical limit on the size of the
buffer
 bounded-buffer assumes that there is a fixed buffer size

1501-352 Operating Systems 1.36

 Bounded-Buffer – Shared-Memory Solution
 Shared data using circular array
#define BUFFER_SIZE 10
typedef struct {
. . .
} item;

item buffer[BUFFER_SIZE];
int in = 0;
int out = 0;
 The buffer is empty when in == out;
 And full when ((in + 1) % BUFFER SIZE) == out.
 Solution is correct, but can only use BUFFER_SIZE-1 elements

1501-352 Operating Systems 1.37

 Bounded-Buffer – Producer

item next_produced;
while (true) {
/* produce an item in next produced */
while (((in + 1) % BUFFER_SIZE) == out)
; /* do nothing */
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE;
}

1501-352 Operating Systems 1.38

 Bounded Buffer – Consumer
item next_consumed;
while (true) {
while (in == out)
; /* do nothing */
next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;

/* consume the item in next consumed */

}

1501-352 Operating Systems 1.39

 Interprocess Communication – Message Passing
 Shared memory:
 access and manipulation code written by the application
programmer.
 Usually used by the processes residing on same system
 Message passing:
 Facility provided by the operating system
Used by processes residing on remote systems.
 MP is a mechanism for processes to communicate and to
synchronize their actions without sharing the same address
space.
 IPC facility provides two operations:
 send(message) – message size fixed or variable
 receive(message)

1501-352 Operating Systems 1.40

 Implementation of communication link
 If P and Q wish to communicate, they need to:
 establish a communication link between them
 exchange messages via send/receive

 Implementation of communication link

 physical (e.g., shared memory, h/w bus, network) [not our
concern here]
 logical (e.g., direct or indirect, synchronous or
asynchronous, automatic or explicit buffering)

Implementation issues:
 How are links established?
 Can a link be associated with more than two processes?
 How many links can be there between every pair of
communicating processes?
 Is a link unidirectional or bi-directional?

1501-352 Operating Systems 1.41

 Direct Communication
 Processes must name each other explicitly [also called
symmetric in addressing]:
 send (P, message) – send a message to process P
 receive(Q, message) – receive a message from process Q
 Asymmetric (in addressing): only the sender names the
recipient; the recipient is not required to name the sender.
 send (P, message) – send a message to process P
 Receive(id, message) – receive a message from any process
[id will be replaced by the receiver in action]
 Properties of communication link in this scheme
 Links are established automatically
 A link is associated with exactly one pair of communicating
processes
 Between each pair there exists exactly one link
 Act as both uni and bi-directional
 Direct Comm. is less flexible and error prone bcoz of the use of
identifiers. 1501-352 Operating Systems 1.42
 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

 Use a mailbox to allow many-to-many communication

 Properties of communication link in this scheme

 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

1501-352 Operating Systems 1.43

 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

1501-352 Operating Systems 1.44

 Indirect Communication
 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.
 Mailbox vs Shared Memory
 Mailbox is like a pipe
 In Mailbox, when a receiver reads a message, it is deleted.

1501-352 Operating Systems 1.45

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

 Blocking is considered synchronous

 Blocking send: The sending process is blocked until the
message is received by the receiving process or by the
mailbox.
 Blocking receive: The receiver blocks until a message is
available.

 Non-blocking is considered asynchronous

 Non-blocking send: The sending process sends the message
and resumes operation.
 Non-blocking receive: The receiver retrieves either a valid
message or a null.

1501-352 Operating Systems 1.46

 Blocking vs. Non-blocking primitives
Blocking
Send Return control to user only
after message has been
sent or an ack. received
from the receiver
Receive Returns only after the
message has been received
Pros and 1. Reduces concurrency
Cons 2. Easy to program
1501-352 Operating Systems
Non-blocking
Control returns as soon as
message queued or copied
Starts receiving message as
soon as it arrives
1. Sending process may not
know when transmission
is done, so it never know
when to re-use the buffer,
sometimes may over-
write the message.
2. Difficult to program
1.47
 Buffering
 Queue of messages attached to the link; implemented in one of
three ways
1. Zero capacity – 0 messages (i.e. no buffering)
Sender must wait for receiver (rendezvous)
2. Bounded capacity – finite length of n messages
Sender must wait if link full
3. Unbounded capacity – infinite length
Sender never waits

1501-352 Operating Systems 1.48

 Communications in Client-Server Systems
 Self study: examples of IPC on Section 3.7 page 132 (Ungraded)

 Shared memory and message passing IPC techniques can be

used for communication in client–server systems.

 However, three other strategies may also be used for

communication in client–server systems

 Sockets (used for networked system)

 Remote procedure call (we will skip this one)
 Pipes (used for same system)

1501-352 Operating Systems 1.49

 Sockets
 A socket is defined as an endpoint for communication

 A socket is identified by 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 consists between a pair of sockets

 All ports below 1024 are well known, used for standard services
 a telnet server listens to port 23; an FTP server listens to
port 21; and a web, or HTTP, server listens to port 80

 Special IP address 127.0.0.1 (loopback) to refer to system on

which process is running
1501-352 Operating Systems 1.50
Socket Communication

1501-352 Operating Systems 1.51

 Sockets in Java
 Three types of sockets

 Connection-oriented (TCP)
 Connectionless (UDP)
 MulticastSocket class– data can be sent to multiple
recipients

1501-352 Operating Systems 1.52

 Pipes
 Acts as a conduit [channel or medium] 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?

1501-352 Operating Systems 1.53

 Ordinary Pipes
 Ordinary Pipes allow communication in standard producer-
consumer style

 Producer writes to one end (the write-end of the pipe)

 Consumer reads from the other end (the read-end of the pipe)

 Ordinary pipes are therefore unidirectional

 Require parent-child relationship between communicating

processes

 Windows calls these anonymous pipes

 See Unix and Windows code samples in textbook (Page 141 to
145)

1501-352 Operating Systems 1.54

 Ordinary Pipes
 On UNIX systems, ordinary pipes are constructed using the
function pipe(int fd[ ])
 This function creates a pipe that is accessed through the int
fd[ ] file descriptors:
 i.e. fd[0] is the read-end of the pipe, and fd[1] is the write-end.

1501-352 Operating Systems 1.55

 Named Pipes
 Named Pipes are more powerful than ordinary pipes (pipe are
named)

 Communication is bidirectional

 No parent-child relationship is necessary between the

communicating processes, any two processes can use it for
communication.

 Several processes can use the named pipe for communication,

(like multiple clients connected to one server)

 Provided on both UNIX and Windows systems

1501-352 Operating Systems 1.56

 Mailbox vs. Pipe
 Are there any differences between a mailbox and a pipe?

 More than two processes

 a pipe often implies one sender and one receiver (except
Linux )
 many can use a mailbox

 Named pipes are connection orientated, mailboxes are not.

 Mailboxes can be used for broadcast, named pipes cannot.

1501-352 Operating Systems 1.57

 Review

Client Server Model

One Host Remote Hosts

Shared Memory Message Passing

Ex: consumer-producer Ex: communication
model channel properties

Pipes Sockets

1501-352 Operating Systems 1.58

 Summary
 Program vs. Process
 Process states
 Process scheduling and schedulers
 Context switch
 Creating a process
 Terminating a process
 IPC
 Shared memory
 Producer consumer model
 Message passing
 Communication channel design
 IPC for Client-Server communication
 Sockets
 Pipes

1501-352 Operating Systems 1.59

Thank You!
Process creation

1501-352 Operating Systems 1.61

Zombie process

1501-352 Operating Systems 1.62

Orphan process

1501-352 Operating Systems 1.63

Executing a command

1501-352 Operating Systems 1.64

1501-352 Operating Systems 1.65