Interprocess Communication

Interprocess Communication
• Consider shell pipeline
– cat chapter1 chapter2 chapter3 | grep tree
– 2 processes
– Information sharing
– Order of execution
 Interprocess Communication
• Processes within a system may be independent or
cooperating
• Cooperating process can affect or be affected by
other processes
• Reasons for cooperating processes:
– Information sharing
– Computation speedup
– Modularity
– Convenience
• Cooperating processes require a mechanism to
exchange data and information
 IPC issues
1. How one process passes information to another ?
2. How to make sure that two or more processes do not get into
each other’s way when engaging in critical activities?
3. How to do proper sequencing when dependencies
are present?
• Ans 1: easy for threads, for processes different approaches
(e.g., message passing, shared memory)
• Ans 2 and Ans 3: same problems and same solutions apply for
threads and processes
– Mutual exclusion & Synchronization

11/17/2018 4 Dept. of CSE, BUET

 Spooling Example: Correct
Process 1 Shared memory
Process 2
int next_free;
int next_free;

… out
1 next_free = in;
4 abc
2 Stores F1 into 5 Prog.c
next_free;
6 Prog.n
3 in=next_free+1 in
7 F1
4 next_free = in
F2
5 Stores F2 into
next_free;

… 6 in=next_free+1

11/17/2018 5 Dept. of CSE, BUET

 Spooling Example: Races
Process 1 Shared memory
Process 2
int next_free;
int next_free;

… out
1 next_free = in;
4 abc
5 Prog.c 2 next_free = in
/* value: 7 */
3 Stores F1 into 6 Prog.n
next_free; in
7 F1
F2
4 in=next_free+1

5 Stores F2 into
next_free;

… 6 in=next_free+1

11/17/2018 6 Dept. of CSE, BUET

 Better Coding?
• In previous code
for(;;){
int next_free = in;
slot[next_free] = file;
in = next_free+1;
}
• What if we use one line of code?
for(;;){
slot[in++] = file
}

11/17/2018 7 Dept. of CSE, BUET

 When Can process Be switched?
• After each machine instruction!
• in++ is a C/C++ statement, translated into
three machine instructions:
– load mem, R
– inc R
– store R, mem
• Interrupt (and hence process swichting) can
happen in between.

11/17/2018 8 Dept. of CSE, BUET

 Race condition
• Two or more processes are reading or writing
some shared data and the final result depends
on who runs precisely when
• Very hard to Debug
 Critical Region
• That part of the program that do critical things
such as accessing shared memory
• Can lead to race condition
 Solution Requirement
1) No two processes simultaneously in critical
region
2) No assumptions made about speeds or numbers of
CPUs
3) No process running outside its critical region may
block another process
4) No process must wait forever to enter its critical
region

11
Solution Requirement

12
 Mutual exclusion With Busy Waiting

• Possible Solutions
– Disabling Interrupts
– Lock Variables
– Strict Alternation
– Peterson’s solution
– TSL

11/17/2018 13 Dept. of CSE, BUET

 Disabling Interrupts
• How does it work?
– Disable all interrupts just after entering a critical section
– Re-enable them just before leaving it.

• Why does it work?

– With interrupts disabled, no clock interrupts can occur
– No switching can occur
• Problems:
– What if the process forgets to enable the interrupts?
– Multiprocessor? (disabling interrupts only affects one CPU)

11/17/2018 14 Dept. of CSE, BUET

 Lock Variables
int lock = 0;
while (lock);
lock = 1;
//EnterCriticalSection;
access shared variable;
//LeaveCriticalSection;
lock = 0;
Does the above code work?
11/17/2018 15 Dept. of CSE, BUET
 Lock Variables
int lock = 0;
while (lock);
Check again here?
lock = 1;
//EnterCriticalSection;
access shared variable;
//LeaveCriticalSection;
lock = 0;
Still doesn’t work!
11/17/2018 16 Dept. of CSE, BUET
 Strict Alternation

(a) Process 0 (b) Process 1

Proposed solution to critical region problem

17
 Problem
• Busy waiting: Continuously testing a variable
until some value appear
– Wastes CPU time
• Violates condition 3
– When one process is much slower than the other

18
 Peterson's solution

• Consists of 2 procedures
• Each process has to call
enter_region(process#)
• enter_region with its
own process # before
entering its C.R.
• And Leave_region leave_region(process#)
after leaving C.R.

19
Peterson's solution (for 2 processes)

20
 Peterson’s Solution: Analysis(1)

• Let Process 1 is not interested and Process 0

calls enter_region with 0
• So, turn = 0 and interested[0] = true and
Process 0 is in CR
• Now if Process 1 calls enter_region, it will hang
there until interested[0] is false. Which only
happens when Process 0 calls leave_region i.e.
leaves the C.R.

21
 Peterson’s Solution: Analysis(2)

• Let both processes call enter_region

simultaneously
• Say turn = 1. (i.e. Process 1 stores last)
• Process 0 enters critical region: while (turn = = 0
&& …) returns false since turn = 1.
• Process 1 loops until process 0 exits: while (turn
= = 1 && interested[0] = = true) returns true.
• It works fine!!

22
 Busy Waiting: Problems
• Waste CPU time since it sits on a tight loop
• May have unexpected effects:
– Priority Inversion Problem
Example:
• 2 Cooperating Processes: H (high priority ) and L (low
priority )
• Scheduling rule: H is run whenever it is ready
• Let L in C. R. and H is ready and wants to enter C.R.
• Since H is ready it is given the CPU and it starts busy waiting
• L will never gets the chance to leave its C.R.
• H loops forever

23
 Sleep & wakeup
• When a process has to wait, change its state to
BLOCKED
• Switched to READY state, when it is OK to retry
entering the critical section
• Sleep is a system call that causes the caller to block
– be suspended until another process wakes it up
• Wakeup system call has one parameter, the process
to be awakened.
• Let’s illustrate the use of sleep & wakeup with an
example: The producer consumer problem
 Producer Consumer Problem
• Also called bounded-buffer problem
• Two (or m+n) processes share a common buffer
• One (or m) of them is (are) producer(s): put(s)
information in the buffer
• One (or n) of them is (are) consumer(s): take(s)
information out of the buffer
• Trouble and solution
– Producer wants to put but buffer full- Go to sleep and
wake up when consumer takes one or more
– Consumer wants to take but buffer empty- go to sleep
and wake up when producer puts one or more
25
Sleep and Wakeup

26
 Sleep and Wakeup

Producer-consumer problem

27
 Sleep and Wakeup: Race condition

• Busy waiting problem is resolved but the

following race condition exists
• Unconstrained access to count
– CPU is given to P just after C has read count to be
0 but not yet gone to sleep.
– P calls wakeup
– Result is lost wake-up signal
– Both will sleep forever

28
 Semaphores
• A new variable type
• A kind of generalized lock
– First defined by Dijkstra in late 60s
– Main synchronization primitive used in original
UNIX
• Semaphores are like integers, except
– No negative values
– Only operations allowed are up and down – can’t
read or write value, except to set it initially
 Semaphores: Types
• Counting semaphore.
– The value can range over an unrestricted domain
• Binary semaphore
– The value can range only between 0 and 1.
– On some systems, binary semaphores are known
as mutex locks as they provide mutual exclusion
 Semaphores: Operation
• Operation “down”:
– if value > 0; value-- and then continue.
– if value = 0; process is put to sleep without completing the
down for the moment
• Checking the value, changing it, and possibly going to sleep, is all done as
an atomic action.
• Operation “up”:
– increments the value of the semaphore addressed.
– If one or more process were sleeping on that
semaphore, one of them is chosen by the system (e.g. at
random) and is allowed to complete its down
• The operation of incrementing the semaphore and waking
up one process is also indivisible
– No process ever blocks doing an up.
31
 Semaphores: Atomicity

– Operations must be atomic

• Two down’s together can’t decrement value
below zero
• Similarly, process going to sleep in down won’t
miss wakeup from up – even if they both
happen at same time

32
Producer & consumer
 Semaphores in Producer Consumer
Problem: Analysis
• 3 semaphores are used
– full (initially 0) for counting occupied slots
– Empty (initially N) for counting empty slots
– mutex (initially 1) to make sure that Producer
and Consumer do not access the buffer at
the same time.
• Here 2 uses of semaphores
– Mutual exclusion (mutex)
– Synchronization (full and empty)
• To guarantee that certain event sequences do or do not occur

34
 Semaphores: Usage
1. Mutual exclusion
2. Controlling access to limited resource
3. Synchronization
 Mutual exclusion
• How to ensure that only one process can enter its C.R.?
• Binary semaphore initialized to 1
• Shared by all collaborating processes
• If each process does a down just before entering CR
and an up just after leaving then mutual exclusion is
guaranteed
do {
down(mutex);
// critical section
up(mutex);
// remainder section
} while (TRUE);
 Controlling access to a resource
• What if we want maximum m process/thread can use a
resource simultaneously ?
• Counting semaphore initialized to the number of
available resources
• Semaphore from railway analogy
– Here is a semaphore initialized to 2 for resource control:
Non critical Critical : 2 Cars permitted at a time Non Critical

Value=2
Value=0
Value=1
 Synchronization
• How to resolve dependency among processes
• Binary semaphore initialized to 0
• consider 2 concurrently running processes:
– P1 with a statement S1 and
– P2 with a statement S2.
– Suppose we require that S2 be executed only after S1
has completed.
P1 P2
S1; down(synch);
up(synch); S2;
 Semaphores: “Be Careful”
• Suppose the following is done in Producer’s code
… … Just the
down(&empty) down(&mutex) order is
down(&mutex) down(&empty)
… …
reversed

• If buffer full P would block due to down(&empty)

with mutex = 0.
• So now if C tries to access the buffer, it would block
too due to its down(&mutex).
• Both processes would stay blocked forever:
DEADLOCK
39
 Monitors
• A higher level
synchronization
primitive
• A collection of
procedures, variables
and data structures
grouped in a special kind
of module or package.
Example of a monitor 40
 Monitors
• Only one process can be active in a monitor at any instant
• Monitors are programming language construct, so the
compiler knows they are special and can handle calls to
monitor procedures differently from other calls.
• Because the compiler, not the programmer, is arranging
the mutual exclusion, it is safer
• We also need a way to block and wakeup: Wait and Signal
(done on a condition variables)

41
 Monitors
• wait is called on some condition variables:
– Calling process is blocked
– another process that had been previously prohibited from
entering the monitor is allowed to enter now.
• signal is called on some condition variable:
– A process waiting on that CV is given the chance to get up.
– Who should run? Caller or awakened one?
Alternative#1: Let newly awakened process to run
suspending the caller.
Alternative#2: Process doing a signal must exit the
monitor immediately i.e. signal statement may 42
appear only as the final statement in a monitor
 Outline of producer-consumer using Monitors

• Outline of producer-consumer problem with monitors

– only one monitor procedure active at one time
– buffer has N slots
43
Producer-consumer solution in Java

44
45
 Problems with monitors and semaphores

– Semaphores are too low level

– Monitors are not usable except in a few programming
languages
– Designed to work in an environment having access to a
common memory
– Doesn’t allow information exchange among machines
– None of them would work in a distributed systems
(why?) consisted of multiple CPUs, each with its own
private memory connected by a LAN.

46
 Message Passing
• solution to the problem of semaphores and
monitors w.r.t distributed systems
• A method of IPC that uses two primitives
– send and receive: system calls.
– send(destination, &message)
– receive(source, &message)
– If no message is available:
• The receiver can block until one arrives
• Return immediately with an error code

47
 Message Passing
• Challenges (Study of Computer Networks)
– Messages can be lost by the network.
– Acknowledgement and retransmission issue.
– Process naming.
– Authentication.
– Performance issue.

48
 Producer Consumer with Message Passing

Assumptions:
•All messages
are of same size
•Messages sent
but not yet
received are
automatically
buffered

The producer-consumer problem with N messages 49

 Dining Philosophers
An example problem for process synchronization

• Philosophers spend their lives

thinking and eating
• Don’t interact with their
neighbors
• When get hungry try to pick up
2 chopsticks (one at a time in
either order) to eat
• Need both to eat, then release
both when done
• How to program the scenario
avoiding all concurrency
problems?
50
Dining Philosophers: A Solution

51
 Dining Philosophers: Problems with
Previous Solution
• Deadlock may happen
• Does this solution
prevents any such thing
from happening ?
– Everyone takes the left
fork simultaneously
 Dining Philosophers: Problems with
Previous Solution
Tentative Solution:
• After taking left fork, check whether right fork is available.
• If not, then return left one, wait for some time and
repeat again.
Problem:
• All of them start and do the algorithm synchronously and
simultaneously:
• STARVATION (A situation in which all the
programs run indefinitely but fail to make any
progress)
• Solution: Random wait; but what if the most unlikely of
same random number happens?
53
 Another Attempt, Successful!
void philosopher(int i) • Theoretically solution is
{
while (true)
OK- no deadlock, no
{ starvation.
think(); • Practically with a
down(&mutex);
take_fork(i);
performance bug:
take_fork((i+1)%N); – Only one philosopher
eat(); can be eating at any
put_fork(i); instant: absence of
put_fork((i+1)%N); parallelism
up(&mutex);
}
}
54
Final Solution part 1

55
Final Solution Part 2

56
 The Readers and Writers Problem
• Dining Philosopher Problem: Models processes that
are competing for exclusive access to a limited
resource
• Readers Writers Problem: Models access to a
database
Example: An airline reservation system- many
competing process wishing to read and write-
– Multiple readers simultaneously- acceptable
– Multiple writers simultaneously- not acceptable
– Reading, while write is writing- not acceptable

57
 The Readers and Writers Problem
• First variation – no reader kept waiting unless
writer has permission to use shared object
• Second variation – once writer is ready, it
performs write ASAP

58
A solution to the readers and writers problem

59
 Issue regarding the solution
• Inherent priority to the readers
• Say a new reader arrives every 2 seconds and
each reader takes 5 seconds to do its work.
What will happen to a writer?
Issue regarding second variation
• Writer don’t have to wait for readers that
came along after it
• Less concurrency, lower performance

60
Thanks for your sincerity