Unit 4

Interprocess Communication
Inter-process communication (IPC)
� Inter-process communication is the mechanism
provided by the operating system that allows
processes to communicate with each other.
�This communication could involve a process letting
another process know that some event has occurred
or transferring of data from one process to another.
�Processes in a system can be independent or
cooperating.
⮩ Independent process cannot affect or be affected by the Inter-process
execution of another process. Communication
⮩ Cooperating process can affect or be affected by the Process - 1 Process - 2
execution of another process.
�Cooperating processes need inter process
communication mechanisms.
Inter-process communication (IPC)
�Reasons of process cooperation
⮩ Information sharing: Several processes may need to access the same data (such as stored in a file.)
⮩ Computation speed-up: A task can often be run faster if it is broken into subtasks and distributed among
different processes.
⮩ Modularity: It may be easier to organize a complex task into separate subtasks, then have different
processes or threads running each subtask.
⮩ Convenience: An individual user can run several programs at the same time, to perform some task.

�Issues of process cooperation

⮩ Data corruption, deadlocks, increased complexity
⮩ Requires processes to synchronize their processing

�Purpose of IPC
⮩ Data transfer : one process may wish to send data to another process
⮩ Sharing data: multiple process may wish to share data if process modifies data that change will be
immediately visible to other
⮩ Event modification : when one process notify another process for occurring some event
⮩ Resource sharing : for resource allocation
Approaches for Inter-Process Communication
Approaches for Inter-Process Communication

Pipes
⮩ It is a half-duplex method (or one-way communication) used for IPC between two related processes.
⮩ It is like a scenario like filling the water with a tap into a bucket. The filling process is writing into the pipe
and the reading process is retrieved from the pipe.

Indirect Communication
● Pairs of communicating processes have shared mailboxes.
● Link (unidirectional or bi-directional) is established between pairs of processes.
● Sender process puts the message in the port or mailbox of a receiver process and receiver process takes out (or
deletes) the data from the mailbox.

FIFO
● Used to communicate between two processes that are not related.
 Approaches for Inter-Process Communication

Message Queue Direct Communication

⮩ We have a linked list to store messages in a
⮩ A pair of communicating processes must
kernel of OS and a message queue is
identified using "message queue identifier". have one link between them.
⮩ A link (generally bi-directional) establishes
between every pair of communicating
processes.
Message passing and Shared Memory
� Message Passing � Shared Memory
⮩ Process A send the message to Kernel and ⮩ Process A put the message into Shared
then Kernel send that message to Process B Memory and then Process B read that
message from Shared Memory

Process - A M

Process - B

Kernel M
The Producer Consumer Problem
� It is multi-process synchronization problem.
� It is also known as bounded buffer problem.
� This problem describes two processes producer
and consumer, who share common, fixed size Producer Buffer Consumer
buffer.
� Producer process
⮩ Produce some information and put it into buffer
� Consumer process
⮩ Consume this information (remove it from the buffer)
What Producer Consumer problem is?
� Buffer is empty
⮩ Producer want to produce √
⮩ Consumer want to consume X
� Buffer is full
Producer Buffer Consumer
⮩ Producer want to produce X
⮩ Consumer want to consume √
� Buffer is partial filled
⮩ Producer want to produce √
⮩ Consumer want to consume √
Producer Consumer problem using Sleep & Wakeup
#define N 4 count 01
int count=0;
item Item 1
void producer (void)
{ int item; Producer Buffer Consumer
1
while (true)
2
{ item=produce_item();
3
if (count==N) sleep();#(if buffer is full) 4
insert_item(item);
count=count+1;
if(count==1) wakeup(consumer);#(to wake up
the consumer because it already in sleep due to empty
buffer)#
}
}
Producer Consumer problem using Sleep & Wakeup
void consumer (void) count 01
{ int item;
item
while (true)
{ if (count==0) sleep(); Producer Buffer Consumer

item=remove_item(); 1 Item 1
2
count=count-1;
3
if(count==N-1) # to wake up the producer 4
wakeup(producer);
consume_item(item);# consume item after
wakeup
}
}
Problem in Sleep & Wakeup
� Problem with this solution is that it contains a race condition that can lead to a deadlock.
(How???)
#define N 4 Producer void consumer (void) Consumer
int count=0; { int item; Context
count 01 Switching
void producer (void) while (true)
{ int item; item Item 1 { if (count==0) sleep();
while (true) item=remove_item();
{ item=produce_item(); Buffer count=count-1;
if (count==N) sleep(); 1 if(count==N-1)
insert_item(item); 2 Item 2 wakeup(producer);
3 Item 3
count=count+1; consume_item(item);
4 Item 4
if(count==1) }
wakeup(consumer); }
Wakeup
} Signal
}
Problem in Sleep & Wakeup
� The consumer has just read the variable count, noticed it's zero and is just about to move
inside the if block.
� Just before calling sleep, the consumer is suspended and the producer is resumed.
� The producer creates an item, puts it into the buffer, and increases count.
� Because the buffer was empty prior to the last addition, the producer tries to wake up the
consumer.
� Unfortunately the consumer wasn't yet sleeping, and the wakeup call is lost.
� When the consumer resumes, it goes to sleep and will never be awakened again. This is
because the consumer is only awakened by the producer when count is equal to 1.
� The producer will loop until the buffer is full, after which it will also go to sleep.
� Finally, both the processes will sleep forever. This solution therefore is unsatisfactory.
Semaphore
� We want functions insert _item and remove_item such that the following hold:
⮩ Mutually exclusive access to buffer: At any time only one process should be executing (either insert_item or
remove_item).
⮩ No buffer overflow: A process executes insert_item only when the buffer is not full (i.e., the process is
blocked if the buffer is full).
⮩ No buffer underflow: A process executes remove_item only when the buffer is not empty (i.e., the process is
blocked if the buffer is empty).
⮩ No busy waiting. should not wait continuously
⮩ No producer starvation: A process does not wait forever at insert_item() provided the buffer repeatedly
becomes full.
⮩ No consumer starvation: A process does not wait forever at remove_item() provided the buffer repeatedly
becomes empty.
Operations on Semaphore
� Wait(): a process performs a wait operation to tell the semaphore that it wants exclusive
access to the shared resource.
⮩ If the semaphore is empty, then the semaphore enters the full state and allows the process to continue its
execution immediately.
⮩ If the semaphore is full, then the semaphore suspends the process (and remembers that the process is
suspended).
� Signal(): a process performs a signal operation to inform the semaphore that it is finished
using the shared resource.
⮩ If there are processes suspended on the semaphore, the semaphore wakes one of the up.
⮩ If there are no processes suspended on the semaphore, the semaphore goes into the empty state.
Producer Consumer problem using Semaphore
#define N 4 mutex 01
typedef int semaphore;
semaphore mutex=1; empty 43
semaphore empty=N;
full 01
semaphore full=0;
void producer (void)
item Item 1
{ int item;
while (true)
Producer Buffer Consumer
{ item=produce_item();
1
down(&empty);
2
down(&mutex);
3
insert_item(item);
4
up(&mutex);
up(&full); }
}
Producer Consumer problem using Semaphore
void consumer (void) mutex 01
{ int item;
while (true) empty 43
{
full 01
down(&full);
down(&mutex);
item
item=remove_item(item);
up(&mutex);
Producer Buffer Consumer
up(&empty);
1 Item 1
consume_item(item);
2
}
3
}
4
Monitor
Monitor
� A higher-level synchronization primitive.
� A monitor is a collection of procedures, variables, and data structures that are all grouped
together in a special kind of module or package.
� Processes may call the procedures in a monitor whenever they want to, but they cannot
directly access the monitor’s internal data structures from procedures declared outside the
monitor.
� Monitors have an important property for achieving mutual exclusion: only one process can be
active in a monitor at any instant.
� When a process calls a monitor procedure, the first few instructions of the procedure will
check to see if any other process is currently active within the monitor.
� If so, the calling process will be suspended until the other process has left the monitor. If no
other process is using the monitor, the calling process may enter.
Producer Consumer problem using Monitor
� The solution proposes condition variables, along with two operations on them, wait and signal.
� When a monitor procedure discovers that it cannot continue (e.g., the producer finds the buffer
full), it does a wait on some condition variable, full.
� This action causes the calling process to block. It also allows another process that had been
previously prohibited from entering the monitor to enter now.
� This other process the consumer, can wake up its sleeping partner by doing a signal on the
condition variable that its partner is waiting on.
� To avoid having two active processes in the monitor at the same time a signal statement may
appear only as the final statement in a monitor procedure.
� If a signal is done on a condition variable on which several processes are waiting, only one of
them, determined by the system scheduler, is revived.
Producer Consumer problem using Monitor
monitor ProducerConsumer
condition full, empty;
integer count;
procedure producer;
begin
while true do
begin
item=produce_item;
ProducerConsumer.insert(item);
end; procedure insert (item:integer);
end; begin
if count=N then wait (full);
insert_item(item);
count=count+1;
if count=1 then signal (empty);
end;
Producer Consumer problem using Monitor
procedure consumer;
begin
while true do
begin
item=ProducerConsumer.remove;
Consume_insert(item);
end; function remove:integer;
end; begin
if count=0 then wait (empty);
remove=remove_item;
count=count-1;
if count=N-1 then signal (full);
end;
count=0;
end monitor;
Classical IPC Problems
Readers & Writer Problem
Readers & Writer Problem
� In the readers and writers problem, many competing processes are wishing to perform reading
and writing operations in a database.
Need to keep track of
P1 P2 P3 P1 P2 P3 read of more than one
process at a time

Read X Read X Read Read √ Read √ 3 Reader_count

Write Write Write Write Write
X X X X

DATABASE DATABASE

� It is acceptable to have multiple processes reading the database at the same time, but if one
process is updating (writing) the database, no other processes may have access to the
database, not even readers.
Readers & Writer Problem
typedef int semaphore;
semaphore mutex=1; //control access to reader count
semaphore db=1; //control access to database
int reader_count=0; //number of processes reading database
Readers & Writer Problem
void Reader (void)
{ while (true) {
down(&mutex); //gain access to reader count
reader_count=reader_count+1; //increment reader counter
if(reader_count==1) //if this is first process to read DB
down(&db) //prevent writer process to access DB
up(&mutex) //allow other process to access reader_count
read_database();
down(&mutex); //gain access to reader count
reader_count=reader_count-1; //decrement reader counter
if(reader_count==0) //if this is last process to read DB
up(&db) //leave the control of DB, allow writer process
up(&mutex) //allow other process to access reader_count
use_read_data(); } //use data read from DB (non-critical)
}
Readers & Writer Problem
void Writer (void)
{ while (true) {
create_data(); //create data to enter into DB (non-critical)
down(&db); //gain access to DB
write_db(); //write information to DB
up(&db); } //release exclusive access to DB
}
Classical IPC Problems
Dining Philosopher Problem
Dining Philosopher Problem
� In this problem 5 philosophers sitting at a round table
doing 2 things eating and thinking.
� While eating they are not thinking and while thinking
they are not eating.
� Each philosopher has plates that is total of 5 plates.
� And there is a fork place between each pair of adjacent
philosophers that is total of 5 forks.
� Each philosopher needs 2 forks to eat and each
philosopher can only use the forks on his immediate
left and immediate right.
The five Philosophers are represented as P0, P1, P2, P3, and P4 and five
chopsticks by C0, C1, C2, C3, and C4.

1. Void Philosopher
2. {
3. while(1)
4. {
5. take_chopstick[i];
6. take_chopstick[ (i+1) % 5] ;
7. ..
8. . EATING THE NOODLE
9. .
Suppose Philosopher P0 wants to eat, it will enter in Philosopher() function, and execute
10. put_chopstick[i] );
11. put_chopstick[ (i+1) % 5] ; take_chopstick[i]; by doing this it holds C0 chopstick after that it execute take_chopstick[
12. . (i+1) % 5]; by doing this it holds C1 chopstick( since i =0, therefore (0 + 1) % 5 = 1)
13. . THINKING
Similarly suppose now Philosopher P1 wants to eat, it will enter in Philosopher() function,
14. }
15. } and execute take_chopstick[i]; by doing this it holds C1 chopstick after that it execute
take_chopstick[ (i+1) % 5]; by doing this it holds C2 chopstick( since i =1, therefore (1 + 1) %
5 = 2)

But Practically Chopstick C1 is not available as it has already been taken by philosopher
P0, hence the above code generates problems and produces race condition.
The solution of the Dining Philosophers Problem

We use a semaphore to represent a chopstick Wait and Signal operations will be used for the solution of the Dining Philosophers
Problem, for picking a chopstick wait operation can be executed while for releasing a chopstick signal semaphore can be
executed. STRUCTURE OF SEMAPHORE
SOLUTION FOR DINING PHILOSOPHER 1. wait( S )
1. semaphore C[5]; 2. {
2. void Philosopher 3. while( S <= 0) ;
3. { 4. S--;
4. while(1) 5. }
5. { 6.
6. Wait( take_chopstickC[i] ); 7. 2. signal( S )
7. Wait( take_chopstickC[(i+1) % 5] ) ; 8. {
8. .. 9. S++;
9. . EATING THE NOODLE 10. }
10. .
11. Signal( put_chopstickC[i] );
12. Signal( put_chopstickC[ (i+1) % 5] ) ;
13. .
14. . THINKING
15. }
16. }
Dining Philosopher Problem
#define N 5 //no. of philosophers
#define LEFT (i) //no. of i’s left neighbor
#define RIGHT (i+1)%5 //no. of i’s right neighbor
#define THINKING 0 //Philosopher is thinking
#define HUNGRY 1 //Philosopher is trying to get forks
#define EATING 2 //Philosopher is eating
typedef int semaphore; //semaphore is special kind of int
int state[N]; //array to keep track of everyone’s state
semaphore mutex=1; //mutual exclusion for critical region
semaphore s[N]; //one semaphore per philosopher
Dining Philosopher Problem
void philosopher (int i) //i: philosopher no, from 0 to N-1 void take_forks (int i) //i: philosopher no, from 0 to N-1
{ { down(&mutex); //enter critical region
state[i]=HUNGRY; //record fact that philosopher i is hungry
while (true) test(i); //try to acquire 2 forks
{ up(&mutex); //exit critical region
think(); //philosopher is thinking down(&s[i]); //block if forks were not acquired
}
take_forks(i); //acquire two forks or block
void test (i) //i: philosopher no, from 0 to N-1
eat(); //eating spaghetti
{ if (state[i]==HUNGRY && state[LEFT]!=EATING && state[RIGHT]!=EATING)
put_forks(i); //put both forks back on table { state[i]=EATING;
} up (&s[i]); }
}
}
void put_forks (int i) //i: philosopher no, from 0 to N-1
{ down(&mutex); //enter critical region
state[i]=THINKING; //philosopher has finished eating
test(LEFT); //see if left neighbor can now eat
test(RIGHT); // see if right neighbor can now eat
up(&mutex); // exit critical region
}
The drawback of the above solution of the dining philosopher problem

The drawback of the above solution is that this solution can lead to a deadlock condition. This situation happens if all the
philosophers pick their left chopstick at the same time, which leads to the condition of deadlock and none of the philosophers can
eat.

To avoid deadlock, some of the solutions are as follows -

● Maximum number of philosophers on the table should not be more than four, in this case, chopstick C4 will be available for
philosopher P3, so P3 will start eating and after the finish of his eating procedure, he will put down his both the chopstick C3
and C4, i.e. semaphore C3 and C4 will now be incremented to 1. Now philosopher P2 which was holding chopstick C2 will also
have chopstick C3 available, hence similarly, he will put down his chopstick after eating and enable other philosophers to eat.
● A philosopher at an even position should pick the right chopstick and then the left chopstick while a philosopher at an odd
position should pick the left chopstick and then the right chopstick.
● Only in case if both the chopsticks ( left and right ) are available at the same time, only then a philosopher should be allowed to
pick their chopsticks
 ● All the four starting philosophers ( P0, P1, P2, and P3) should pick the left chopstick and then the right chopstick, whereas the
last philosopher P4 should pick the right chopstick and then the left chopstick. This will force P4 to hold his right chopstick first
since the right chopstick of P4 is C0, which is already held by philosopher P0 and its value is set to 0, i.e C0 is already 0,
because of which P4 will get trapped into an infinite loop and chopstick C4 remains vacant. Hence philosopher P3 has both left
C3 and right C4 chopstick available, therefore it will start eating and will put down its both chopsticks once finishes and let
others eat which removes the problem of deadlock.

The design of the problem was to illustrate the challenges of avoiding deadlock, a deadlock state of a system is a state in which no
progress of system is possible. Consider a proposal where each philosopher is instructed to behave as follows:

● The philosopher is instructed to think till the left fork is available, when it is available, hold it.
● The philosopher is instructed to think till the right fork is available, when it is available, hold it.
● The philosopher is instructed to eat when both forks are available.
● then, put the right fork down first
● then, put the left fork down next
● repeat from the beginning.