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 others way when engaging in critical activities?
3. How to do proper sequencing when dependencies are
present?
1: easy for threads, for processes different approaches (e.g.,
message passing, shared memory)
2 and 3: same problems and same solutions apply for
threads and processes
Mutual exclusion & Synchronization

8/16/17
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

8/16/17 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

8/16/17 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
}
8/16/17
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.

8/16/17
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
Petersons solution
TSL

8/16/17
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)
Only used inside OS

8/16/17
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?
8/16/17
15 Dept. of CSE, BUET
 STRICT ALTERNATION

(a) Process 0 (b) Process 1

Proposed solution to critical region problem

16
 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

17
 PETERSON'S SOLUTION

Consists of 2
procedures
enter_region(proc
Each process has to ess#)
call
enter_region with
its own process # leave_region(proc
before entering its ess#)
C.R.
And Leave_region
after leaving C.R.
18
PETERSON'S SOLUTION (FOR 2 PROCESSES)

19
 PETERSONS 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.

20
 PETERSONS 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.
Done!!

21
 TSL
Requires hardware support
TSL instruction: test and set lock
Reads content of lock into a Register
Indivisible/Atomic
Stores a nonzero value at lock.
CPU executing TSL locks the memory bus prohibiting
other CPUs from accessing memory

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
http://
research.microsoft.com/en-us/um/people/mbj/Mars_Pathfinder/
Mars_Pathfinder.html
23
 SLEEP & WAKEUP

When a process has to wait, change its state to

BLOCKED/WAITING
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.
 PRODUCER CONSUMER PROBLEM
Also called bounded-buffer problem
Two (m+n) processes share a common buffer
One (m) of them is (are) producer(s): put(s) information
in the buffer
One (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

PRODUCER-CONSUMER PROBLEM
SLEEP AND WAKEUP

27

PRODUCER-CONSUMER PROBLEM
 SLEEP AND WAKEUP: RACE
CONDITION
Race condition
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 cant read or
write value, except to set it initially
 SEMAPHORES
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.
30
 SEMAPHORES
Operations must be atomic
Two downs together cant decrement value
below zero
Similarly, process going to sleep in down wont
miss wakeup from up even if they both
happen at same time

31
 SEMAPHORES

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 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
guarrented
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;
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

38
 SEMAPHORES: BE CAREFUL
Suppose the following is done in Producers code
Just the
down(&empty) down(&mutex) order is
down(&mutex) down(&empty)

reversed

If buffer full Producer would block due to

down(&empty) with mutex = 0.
So now if Consumer tries to access the buffer, it would
block too due to its down(&mutex).
Both processes would stay blocked forever: DEADLOCK

39
 DINING PHILOSOPHERS
Philosophers spend their lives
thinking and eating
Dont 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?

40
DINING PHILOSOPHERS: A SOLUTION

41
 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?
43
 ANOTHER ATTEMPT, SUCCESSFUL!
void philosopher(int i) Theoretically solution is OK-
{ no deadlock, no starvation.
while (true)
{
Practically with a
think(); performance bug:
down(&mutex); Only one philosopher can be
take_fork(i); eating at any instant:
take_fork((i+1)%N); absence of parallelism
eat();
put_fork(i);
put_fork((i+1)%N);
up(&mutex);
}
}
44
FINAL SOLUTION PART 1

45
FINAL SOLUTION PART 2

46
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

47
A solution to the readers and writers problem

48
 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 dont have to wait for readers that came along after
it
Less concurrency, lower performance

49
THANKS FOR YOUR
PATIENCE