Outline

 Process Concept
 Process Scheduling
 Operations on Processes
 Cooperating Processes
 Interprocess Communication
Process Concept

 An operating system executes a variety of

programs
 batch systems - jobs
 time-shared systems - user programs or tasks
 job and program used interchangeably
 Process - a program in execution
 process execution proceeds in a sequential fashion
 A process contains
 program counter, stack and data section
Process State

 A process changes state as it executes.

new admitted
new exit terminated

interrupt

running
ready

Scheduler
I/O or dispatch
event I/O or
completion event wait

waiting
Process States

 New - The process is being created.

 Running - Instructions are being executed.
 Waiting - Waiting for some event to occur.
 Ready - Waiting to be assigned to a
processor.
 Terminated - Process has finished execution.
Process Control Block

 Contains information associated with each

process
 Process State - e.g. new, ready, running etc.
 Program Counter - address of next instruction to be
executed
 CPU registers - general purpose registers, stack pointer
etc.
 CPU scheduling information - process priority, pointer
 Memory Management information - base/limit information
 Accounting information - time limits, process number
 I/O Status information - list of I/O devices allocated
Process Scheduling Queues
 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.
 Process migration between the various queues.
 Queue Structures - typically linked list, circular list
etc.
Process Queues

Device
Queue

Ready
Queue
Process Scheduling Queues
Schedulers
 Long-term scheduler (or job scheduler) -
 selects which processes should be brought into the ready
queue.
 invoked very infrequently (seconds, minutes); may be slow.
 controls the degree of multiprogramming
 Short term scheduler (or CPU scheduler) -
 selects which process should execute next and allocates
CPU.
 invoked very frequently (milliseconds) - must be very fast
 Medium Term Scheduler
 swaps out process temporarily
 balances load for better throughput
Medium Term (Time-sharing)
Scheduler
Process Profiles

 I/O bound process -

 spends more time in I/O, short CPU bursts, CPU
underutilized.
 CPU bound process -
 spends more time doing computations; few very long CPU
bursts, I/O underutilized.
 The right job mix:
 Long term scheduler - admits jobs to keep load balanced
between I/O and CPU bound processes
Context Switch

 Task that switches CPU from one process to

another process
 the CPU must save the PCB state of the old process and
load the saved PCB state of the new process.
 Context-switch time is overhead;
 system does no useful work while switching
 can become a bottleneck
 Time for context switch is dependent on
hardware support ( 1- 1000 microseconds).
Process Creation
 Processes are created and deleted
dynamically
 Process which creates another process is
called a parent process; the created process
is called a child process.
 Result is a tree of processes
 e.g. UNIX - processes have dependencies and form a
hierarchy.
 Resources required when creating process
 CPU time, files, memory, I/O devices etc.
UNIX Process Hierarchy
Process Creation

 Resource sharing
 Parent and children share all resources.
 Children share subset of parent’s resources - prevents many
processes from overloading the system.
 Execution
 Parent and child execute concurrently.
 Parent waits until child has terminated.
 Address Space
 Child process is duplicate of parent process.
 Child process has a program loaded into it.
UNIX Process Creation

 Fork system call creates new processes

 execlp system call is used after a fork to

replace the processes memory space with a
new program.
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 child
processes.
 Child has exceeded allocated resources.
 Task assigned to child is no longer required.
 Parent is exiting
 OS does not allow child to continue if parent terminates
 Cascading termination
Interprocess Communication
(IPC)
 Mechanism for processes to communicate and
synchronize their actions.
 Via shared memory
 Via Messaging system - processes communicate without resorting to
shared variables.
 Messaging system and shared memory not mutually
exclusive -
 can be used simultaneously within a single OS or a single process.
 IPC facility provides two operations.
 send(message) - message size can be fixed or variable
 receive(message)
Producer-Consumer using IPC
 Producer
repeat
…
produce an item in nextp;
…
send(consumer, nextp);
until false;
 Consumer
repeat
receive(producer, nextc);
…
consume item from nextc;
…
until false;
Cooperating Processes via
Message Passing
 If processes P and Q wish to communicate,
they need to:
 establish a communication link between them
 exchange messages via send/receive
 Fixed vs. Variable size message
 Fixed message size - straightforward physical
implementation, programming task is difficult due to
fragmentation
 Variable message size - simpler programming, more
complex physical implementation.
Implementation Questions
 How are links established?
 Can a link be associated with more than 2
processes?
 How many links can there be between every pair
of communicating processes?
 What is the capacity of a link?
 Fixed or variable size messages?
 Unidirectional or bidirectional links?
…….
Direct Communication

 Sender and Receiver 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.
 Exactly one link between each pair.
 Link may be unidirectional, usually bidirectional.
Indirect Communication
 Messages are directed to and received from
mailboxes (also called ports)
 Unique ID for every mailbox.
 Processes can communicate only if they share a mailbox.
Send(A, message) /* send message to mailbox A */
Receive(A, message) /* receive message from mailbox A */
 Properties of communication link
 Link established only if processes share a common mailbox.
 Link can be associated with many processes.
 Pair of processes may share several communication links
 Links may be unidirectional or bidirectional
Indirect Communication using
mailboxes
Mailboxes (cont.)
 Operations
 create a new mailbox
 send/receive messages through mailbox
 destroy a mailbox
 Issue: Mailbox sharing
 P1, P2 and P3 share mailbox A.
 P1 sends message, P2 and P3 receive… who gets
message??
 Possible Solutions
 disallow links between more than 2 processes
 allow only one process at a time to execute receive operation
 allow system to arbitrarily select receiver and then notify
sender.
Message Buffering

 Link has some capacity - determine the

number of messages that can reside
temporarily in it.
 Queue of messages attached to link
 Zero-capacity Queues: 0 messages
 sender waits for receiver (synchronization is called
rendezvous)
 Bounded capacity Queues: Finite length of n messages
 sender waits if link is full
 Unbounded capacity Queues: Infinite queue length
 sender never waits
Message Problems -
Exception Conditions
 Process Termination
 Problem: P(sender) terminates, Q(receiver) blocks forever.
 Solutions:
 System terminates Q.
 System notifies Q that P has terminated.
 Q has an internal mechanism(timer) that determines how long to wait
for a message from P.
 Problem: P(sender) sends message, Q(receiver) terminates.
In automatic buffering, P sends message until buffer is full or
forever. In no-buffering scheme, P blocks forever.
 Solutions:
 System notifies P
 System terminates P
 P and Q use acknowledgement with timeout
Message Problems -
Exception Conditions
 Lost Messages
 OS guarantees retransmission
 sender is responsible for detecting it using timeouts
 sender gets an exception
 Scrambled Messages
 Message arrives from sender P to receiver Q, but information
in message is corrupted due to noise in communication
channel.
 Solution
 need error detection mechanism, e.g. CHECKSUM
 need error correction mechanism, e.g. retransmission
Cooperating Processes
 Concurrent Processes can be
 Independent processes
 cannot affect or be affected by the execution of another
process.
 Cooperating processes
 can affect or be affected by the execution of another process.
 Advantages of process cooperation:
 Information sharing
 Computation speedup
 Modularity
 Convenience(e.g. editing, printing, compiling)
 Concurrent execution requires
 process communication and process synchronization
Producer-Consumer Problem

 Paradigm for cooperating processes;

 producer process produces information that is
consumed by a consumer process.
 We need buffer of items that can be filled by
producer and emptied by consumer.
 Unbounded-buffer places no practical limit on the size of the
buffer. Consumer may wait, producer never waits.
 Bounded-buffer assumes that there is a fixed buffer size.
Consumer waits for new item, producer waits if buffer is full.
 Producer and Consumer must synchronize.
Producer-Consumer Problem
Bounded-buffer - Shared
Memory Solution
 Shared data
var n;
type item = ….;
var buffer: array[0..n-1] of item;
in, out: 0..n-1;
in :=0; out:= 0; /* shared buffer = circular array */
/* Buffer empty if in == out */
/* Buffer full if (in+1) mod n == out */
/* noop means ‘do nothing’ */
Bounded Buffer - Shared
Memory Solution
 Producer process - creates filled buffers
repeat
…
produce an item in nextp
…
while in+1 mod n = out do noop;
buffer[in] := nextp;
in := in+1 mod n;
until false;
Bounded Buffer - Shared
Memory Solution
 Consumer process - Empties filled buffers
repeat
while in = out do noop;
nextc := buffer[out] ;
out:= out+1 mod n;
…
consume the next item in nextc
…
until false