Processes

https://www.youtube.com/watch?v=ss1-REMJ9GA
6:21

forked clones
https://www.youtube.com/watch?v=kDxjcyHu_Qs
Processes
 To introduce the notion of a
process -- a program in
execution, which forms the basis

Objectives of all computation

To describe the various features

of processes, including
scheduling, creation and
termination, and communication

To explore interprocess
communication using shared
memory and message passing

To describe communication in
client-server systems
 Process Concept

 Process – a program in execution; process

execution must progress in sequential fashion

 Process > Program Multiple parts

 The program code, also called text section
 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
What is a Heap?
 Process Concept (Cont.)
 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 become several processes
 Consider multiple users executing the same program (e.g. email
program, web browser)
 A process can also be an execution environment for
other code
 Java programming environment is a good example.
 An executable Java program is executed within the JVM.
 JVM executes as a process that interprets the loaded Java
code and takes actions via native machine instructions on
behalf of that code.
 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
 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 (Process
Control Block)
● 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
● Context-switch time dependent on hardware support
● Some hardware provides multiple sets of registers per CPU ➔
multiple contexts loaded at once and a pointer is used to
indicate the active context
This is another example of where hardware manufacturers
have implemented OS software features.
 Process Control Block (PCB)

Information associated with each process

(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
CPU Switch From Process to Process
 Threads

 So far, process has a single thread of execution

 Consider having multiple program counters per
process
 Multiple locations can execute at once
 Multiple threads of control -> threads
 PCB expanded to include thread details, multiple
program counters.
 LOTS more about threads coming in the next
topic.
 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 */
 Process Scheduling

 Multiprogramming goal: Maximize CPU use

 Time sharing goal: quickly switch CPU between processes
for time sharing
 Process scheduler
 Selects among available processes for next execution on CPU
 In a single processor system, there will never be more
than one running process. WHY IS THAT?
 Maintains scheduling queues of processes
 Job queue – entry point of all processes in the system
 Ready queue – set of all processes residing in main
memory, ready and waiting to execute (linked list)
 Device queues – set of processes waiting for an I/O
device

Processes migrate among the various queues

Ready Queue And Various I/O Device Queues

In what state are

these processes?
 Representation of Process Scheduling

Queueing diagram represents queues, resources, flows

 Schedulers
 Long-term scheduler (or job scheduler) – selects
which processes spooled on a mass storage device
should be brought into the ready queue in memory
(usually found in batch environments only)
 Long-term scheduler is invoked infrequently (seconds,
minutes) ⇒ (may be slow)
 The long-term scheduler controls the degree of
multiprogramming
 Short-term scheduler (or CPU scheduler) –
selects which process on the ready queue should be
executed next and allocates CPU
 Sometimes the only scheduler in a system
 Short-term scheduler is invoked frequently (milliseconds)
⇒ (must be fast) it had better be efficient!!
 Schedulers

 Processes can be described as either:

 I/O-bound process – spends more time doing I/O than

computations, many short CPU bursts EXAMPLE?

 CPU-bound process – spends more time doing

computations; few very long CPU bursts EXAMPLE?

 Long-term scheduler strives for good process

mix to ensure utilization of all resources
 Addition of Medium-Term Scheduling
 Medium-term scheduler can be added if
degree of multiprogramming needs to decrease
due to unforeseen rise in memory requirements.
(this is usually found in time-sharing systems)
 Removes process from memory, store on disk, bring back
in from disk to continue execution: swapping (more in
Chapter 8)
 Operations on Processes

 The processes in most (!) systems can execute

concurrently, and they may be created and
deleted dynamically.
 Operating Systems must provide a mechanism
for process creation and termination.
 Process Creation:
 Parent process create children processes, which
may, in turn, create other processes, forming a tree
of processes
 Generally, a process is identified and managed via a
process identifier (pid)
 A Tree of Processes in Linux
sshd is the
daemon
program
for ssh

Bash is a
type of
Linux shell
(replaces
Bourne shell)
Kernel-
related
processe
s

tcsh is a
SSH stands for Secure SHell. It is a program designed type of
to allow users to log into another computer over a Linux
shell
network, to execute commands on that computer and to
move files to and from that computer. It effectively
replaces telnet, ftp and the rcp/rsh/remsh programs.
 Process Creation
 Resource sharing options
 Parent and children share all available OS-
managed resources
 Children share subset of parent’s resources
 When a process creates a new process… .Either
the….
 Parent and children execute concurrently
 Parent waits until some or all children
terminate
 Address space options
 The child process is a duplicate of the parent
process (it has the same program and data as
the parent)
 The child program has a new program loaded
 Process Creation (Cont.)

 UNIX examples
 fork() system call creates new process
 Returns PID to parent process
 Returns 0 (zero) to child process
 If the fork system call is successful, a child process is
produced that continues execution at the point where
it was called by the parent process.
 After the fork system call, both the parent and child
processes are running and continue their execution
at the next statement in the parent process.

https://www.youtube.com/watch?v=ss1-REMJ9GA
 Process Creation (Cont.)
 UNIX examples
 fork() system call creates new process
 Returns PID to parent process
 Returns 0 (zero) to child process
 exec() system call used after a fork() to
replace the process’ memory space with a new
program optional

Identical address spaces

Loads a new program

And new address space
https://www.youtube.com/watch?v=kDxjcyHu_Qs
 C Program Forking Separate Process

•this system call is used when the number

of arguments to be passed to the program
to be executed is known in advance

Wait(NULL) waits for all child processes to complete

Creating a Separate Process via Windows API
 YOUTUBE VIDEOS
•https://www.youtube.com/watch?v=ss1-REMJ9GA
•https://www.youtube.com/watch?v=kDxjcyHu_Qs
It’s a joke.
 Process Termination

 Process executes last statement and then asks

the operating system to delete it using the
exit() system call.
 Returns status data from child to parent (via
wait())
 Process’ resources are deallocated by operating
system
 Parent may terminate the execution of children
processes using the abort()(UNIX) or
TerminateProcess (Windows) 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 operating systems does
not allow a child to continue if its parent terminates
 Process Termination
 Some operating systems do not allow child to exist if its parent
has terminated. If a process terminates, then all its children must
also be terminated.
 cascading termination - initiated by the operating system
 All children, grandchildren, etc. are terminated when
parent process terminates
 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 process has terminated and parent did not yet invoke wait()
process is a zombie
 If parent terminated without invoking wait , process is an
orphan
 Linux and Unix will assign the orphan process as a child of init
that issues wait periodically to allow for graceful exit.
 init is root of process hierarchy in UNIX/LINUX
 Multiprocess Architecture – Chrome Browser

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

 If one web site causes trouble, entire browser can hang or
crash
 Google Chrome Browser is multiprocess with 3 different types
of processes:
 Browser process manages user interface, disk and
network I/O
 Only one Browser process will exist
 Renderer process renders web pages, deals with HTML,
Javascript. A new renderer created for each website
opened
 Runs in sandbox restricting disk and network I/O,
minimizing effect of security exploits
 Plug-in process for each type of plug-in (e.g., Flash,
QuickTime)
 Interprocess Communication

 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 (requires multiple processing
cores)
 Modularity
 Convenience
 Cooperating processes need interprocess
communication (IPC)
 Two models of IPC
 Shared memory
 Message passing
 Communications Models
(a) Message passing (b) shared memory
 Interprocess Communication
Shared Memory

 An area of memory shared among the

processes that wish to communicate
 The communication is under the control of the
users processes not the operating system.
 Goal is to provide mechanism that will allow
the user processes to synchronize their actions
when they access shared memory.
 Synchronization is discussed in GREAT
DETAIL in a later topic.
 Producer-Consumer Problem

 Paradigm for cooperating processes, producer process

produces information that is consumed by a consumer
process
 So, what’s the problem?
 Allowing both processes to run concurrently and not
requiring the consumer to wait until the producer has
terminated.
 One Solution: Shared Memory
 A buffer that is filled by the producer and emptied by
the consumer.
 Producer and consumer must be synchronized so that
the consumer doesn’t try to consume an item that
has not yet been produced.
If you think the answer is trivial.. You may be right…
stay tuned.
 Producer-Consumer Problem

 Two buffer choices:

 unbounded-buffer places no practical limit on

the size of the buffer
 Consumer may have to wait for new items
 Producer can always produce new items
 bounded-buffer assumes that there is a fixed
buffer size
 Consumer may have to wait for new items
 Producer may have to wait if buffer is full
 Bounded-Buffer – Shared-Memory Solution
 Shared data
#define BUFFER_SIZE 10 Treated as a circular array
typedef struct {
. . .
} item;

item buffer[BUFFER_SIZE];
int in = 0; in points to next free position
int out = 0; out points to first full position

 Solution is correct, but can only use BUFFER_SIZE-1 elements

Buffer is empty when in == out

Buffer has unread contents when out < (in%BUFFERSIZE)
Buffer is full when (in+1) % BUFFERSIZE == out
 item next_produced;
while (true) {
/* produce an item in next produced
*/
Bounded- out)
while (((in + 1) % BUFFER_SIZE) ==

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

/* consume the item in next_consumed */

}
 Interprocess Communication
Message Passing
 Mechanism for processes to communicate and to
synchronize their actions
 Particularly useful in distributed systems where processes
may reside on different computers connected by a
network
 Message system – processes communicate with
each other without resorting to shared variables
 IPC facility provides two operations:
 send(message)
 receive(message)
 Interprocess Communication
Message Passing

 The message size is either fixed or variable

 Variable messages are harder for the OS programmer to
implement and make the life of the application
programmer easier.
 Fixed messages are easier for the OS programmer to
implement and make the life of the application
programmer harder.
 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?
 Message Passing (Cont.)

 Implementation of communication link

 Physical:
 Shared memory
 Hardware bus
 Network
 Logical:
 Direct or indirect
 Synchronous or asynchronous
 Automatic or explicit buffering
 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
 Direct Communication
 Symmetric Addressing: sender and receiver name their
partner
 send (P, message) – send a message to process P
 receive(Q, message) – receive a message from process
Q

 Asymmetric Addressing: only sender names partner

 send (P, message) – send a message to process P
 receive(id, message) – receive a message from any
process. Id is set to the id of the sender process.

Significant Disadvantage: If process names change or PID

values change, all referring processes must be modified.
 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 between two processes IFF processes
share a common mailbox
 A link may be associated with many processes
 Each pair of processes may share several communication
links with each link corresponding to one mailbox
 Link may be unidirectional or bi-directional
 Primitives are defined as:
 send(A, message) – send a message to mailbox A
 receive(A, message) – receive a message from
mailbox A
 Indirect Communication
 Mailbox sharing
 P1, P2, and P3 share mailbox A
 P1, sends; P2 and P3 receive
 Who gets the message?
 Assumption (message is consumed when received)
 Solutions
1. Allow a link to be associated with at most two processes
2. Allow only one process at a time to execute a receive
operation
3. Allow the system to select arbitrarily the receiver (or use
an algorithm –e.g., round-robin). Sender is notified who
the receiver was.
 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 by the receiving process or mailbox
 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 resumes operation
 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
 Synchronization (Cont.)

 Producer-consumer problem becomes

trivial
 Producer invokes a non blocking send()
call.
 Consumer invokes a blocking receive()
and waits until a message is available.
 Synchronization (Cont.)

● Producer-consumer problem becomes trivial

message next_produced;
while (true) {
/* produce an item in next produced */
send(next_produced);
}
message next_consumed;
while (true) {
receive(next_consumed);

/* consume the item in next consumed */

}
 Buffering
 Messages exchanged between communicating
processes reside in a temporary queue.
 implemented in one of two ways
 No Buffering System:
 Zero capacity – no messages are queued on a link.
Sender must wait for receiver (rendezvous)
 Automatic Buffering:
 Bounded capacity – finite length of n messages
Sender must wait if link full
 Unbounded capacity – infinite length
Sender never waits
End