IPC | Process (Computing) | Concurrency (Computer Science)

Inter-process Communication 
Independent process cannot affect or be affected by

the execution of another process. 
Cooperating process can affect or be affected by the

execution of another process 
Advantages of process cooperation

‡ Information sharing ‡ Computation speed-up ‡ Modularity ‡ Convenience

Three objectives: 1. Passing information from one process to another 2. Making sure two processes don·t get into each others· way (e.g., trying to grab the last 1MB of memory) 3. Making sure the proper sequencing is implemented (e.g., if process A produces data used by process B, B should not start using the data before A finishes producing it). Discussion applies to threads as well (except 1).

Communication Models
Msg Passing Shared Memory

process A


process A 1 shared memory 2

process B


process B








Definitions  Race Conditions: Two or more processes are reading and writing on shared data and the final result depends on who runs precisely when  Mutual exclusion : Making sure that if one process is accessing a shared memory. the other will be excluded from doing the same thing  Critical region: The part of the program where shared variables are accessed .

Critical Region Mutual exclusion using critical regions .

Requirements for Correct Mutual Exclusion? .

3. 2. No two processes simultaneously in critical region No assumptions made about speeds or numbers of CPUs No process running outside its critical region may block another process 4.Mutual Exclusion Four conditions to provide CORRECT mutual exclusion 1. No process must wait forever to enter its critical region .

Mutual Exclusion  Disabling Interrupts  Busy waiting: Testing a variable until some value appears ‡ Lock Variables ‡ Strict Alternation ‡ Peterson·s Solution ‡ Test and Set Lock (TSL)  Sleep and wakeup  Semaphores. Mutexes  Monitors  Message passing .

 Not suitable approach for the general case but can be used by the Kernel when needed . Only the CPU that executes the disable instruction is affected.Disabling Interrupts  Process disables all interrupts before entering its critical region  (CPU is switched between processes only as a result of interrupts)  Enables all interrupts just before leaving its critical region  So disabling interrupts guarantees that there will be no process switch  Disadvantage: ‡ Should give the power to control interrupts to user (what if a user turns off the interrupts and never turns them on again?) ‡ Does not work in case of multiple CPUs.

set it back to 0 before leaving the critical region. ‡ If lock = 1 then wait until it is set to 0  Does the above scheme work? .Mutual Exclusion with Busy Waiting: Lock Variables  A lock that uses busy waiting is called a spin lock  A single shared lock variable (lock) initially 0  When a process wants to enter its critical region ‡ Check if the lock is 0 ‡ If lock = 0 then set it to 1 and enter the critical region.

Mutual Exclusion with Busy Waiting: Strict Alternation Process 0 Initially turn = 0 Process 1 .

sets turn to 0.Process 1 enters non-critical region.Process 1 enters critical region. and leaves critical region 3. enters non critical region 2.Process 0 Process 1 Scenario: 1.Process 0 leaves critical region. process 1 has to wait for process 0 to finish its non-critical region so that it can enter its critical region This violates the third condition of providing mutual exclusion . quickly finishes its job and goes back to the while loop Since turn is 0. sets turn to 1.

Mutual Exclusion with Busy Waiting: Peterson·s Solution .

CPU executing TSL instruction locks the memory bus to prevent other processors accessing LOCK .Mutual Exclusion with Busy Waiting: TSL Instruction  No other processor can reach LOCK during TSL ‡ In order to achieve that.

. H does busy waiting ²But L is never scheduled while H is running ²And the system is blocked forever.Mutual Exclusion with Busy Waiting  Causes a problem called ´PRIORITY INVERSIONµ  Two processes: H (high priority) and L (Low Priority) ‡ Scheduler must make sure that H is executed whenever it is in ready state Scenario: ²Process H blocks for I/O ²Process L now can execute and enters its critical section ²I/O operation H waits for is now complete ²H is scheduled now but since L is in the critical section.

Producer Consumer Problem (bounded buffer)  Two processes: producer and consumer that share a fixed size buffer  Producer puts an item into the buffer  Consumer takes out an item from the buffer  PROBLEMS: ‡ What happens when the producer wants to put an item into the buffer while the buffer is already full? ‡ OR when the consumer wants to consume an item from the buffer when the buffer is empty? .

Sleep and Wakeup .

and after filling up the buffer it sleeps Both processes sleep forever (or until the OS comes and sends a kill signal to kill both) . which runs N times. the wakeup signal is lost Scheduler decides to run the consumer Consumer sleeps Producer is scheduled. and issues a wakeup call. Since consumer is not sleeping yet.Consumer is running It checks count when count == 0 Scheduler decides to run Producer just before consumer sleeps Producer inserts an item and increments the count Producer notices that count is 1.

Solution: Semaphores by Dijkstra (1930 ² 2002)  A semaphore can be ‡ 0 when no wakeups are present ‡ > 0 when there are pending wakeups  Two atomic operations on a semaphore ‡ Down: checks the value of the semaphore  If value is > 0.  Disabling interrupts when one CPU exists or TSL instruction could be used when multiple CPUs exist . then it decrements it (by using one wakeup signal) and continues  If value = 0. then the process is put to sleep without completing its down operation ‡ Up: increments the value of the semaphore  If there are processes sleeping on the semaphore. then one of them is chosen. and it is allowed to complete its down operation  Checking the value of a semaphore and updating them is done in an atomic fashion.

The producer-consumer problem using semaphores .

down(&mutex). What happens when we do a down on mutex first in the producer function? void producer(void) { int item. while(TRUE){ item=produce_item(). //Buffer is full  Producer will enter the critical region and will not be able to proceed since the buffer is full  Consumer cannot access the critical region since the producer is already present  The system will enter an indefinite state . //Enter critical region down(&empty).

useful for achieving mutual exclusion By turning all the critical regions into monitor procedures. no two processes will execute their CR·s at the same time Mutual exclusion can be achieved using monitors.Monitors Monitor is a collection of procedures. but condition variables are required to block the processes when they cannot proceed: wait and signal . variables and data structures that are grouped together as a module Important property: Only one process can be active in a monitor at any instant.

consume_item(item).remove. end end procedure Consumer. begin while TRUE do begin item = produce_item.insert(item). ProducerConsumer. end end // make a new item // call enter function in monitor // call remove function in monitor // consume an item . begin while TRUE do begin item = ProducerConsumer.procedure Producer().

block remove_item(item). begin if (count == 0) wait(empty).monitor ProducerConsumer condition full. . count := 0. // wake consumer end procedure remove:integer. // if buffer was full. // if buffer is empty.1. wake producer end. // remove item from buffer count := count . end monitor. // increment count of full slots if (count == 1) signal(empty). // decrement count of full slots if (count == N-1) signal(full). begin if (count == N) wait(full). empty. // put item in buffer count := count + 1. integer count. block insert_item(item). // if buffer is full. procedure insert(item:integer).

Rules: Process doing signal must exit the monitor immediately ‡To avoid having two active processes in the monitor at the same time Wait must come before the signal ‡So that signals will not be lost ‡In practice. the process can check the condition variables to see if the operation is necessary Difference between sleep/wakeup and wait/ signal: ‡Race condition cannot occur: Only one process can be running at a time .

Mutexes Implementation of mutex_lock and mutex_unlock using TSL instruction .

then the thread calling the mutex_lock() on that mutex blocks  When a thread calls mutex_unlock. then one of the threads blocked on the mutex is unblocked and allowed to acquire the lock. it calls mutex_lock() on a mutex  While leaving the critical region it calls mutex_unlock()  If a mutex is already in locked state.Mutexes  Simplified versions of semaphores  Variable that can be in one of two states : ‡ Locked (1) ‡ Unlocked (0)  When a thread (or process) needs access to a critical region. .

// sends message to destination // receives message from source . each with its own private memory. connected by a LAN Uses two primitives: send and receive which are system calls rather than language constructs send(destination.Message Passing Semaphores. &message). monitors solve mutual exclusion between one or more CPUs that have access to a common memory MP: For a distributed system consisting of multiple CPUs. &message). receive(source.

#define N 100 void producer(void) { int item.i<N. } } void consumer(void) { int item. for (i=0. receive(consumer. build_message(&m. &m).&m). item). message m.&m).i++) send(producer. message m. while(TRUE){ receive(producer. i. &m). consume_item(item).&m). while(TRUE){ item=produce_item(). send(producer. } } //wait for an empty to arrive //construct a message to send //send item to consumer //send N empties //get message containing item //extract item from message //send back empty reply . send(consumer. item=extract_item(&m).

To avoid this acknowledgement can be sent by the receiver and the sender ‡If message is sent and acknowledgement is lost. retransmission may happen (duplication of msgs) Authentication: Authenticating the sender and the receiver Performance: Copying messages from one process to another is always slower than doing a semaphore operation or entering a monitor .Design Issues: Messages can be lost.

Barriers Useful for groups of processes rather than two processes No process may proceed into the next phase until all processes are ready to proceed to the next phase Can be achieved using barriers No process may start on iteration n+1 until iteration n is complete .

A B a r r i e r D A B a r r i e r B a r r i e r A Process B B B C C C D D Time Time Time .

) Models access to a database (both read and write) Sleeping barber problem Models queuing situations such as a multi-person helpdesk with a computerized call waiting system for holding a limited number of incoming calls .Classical IPC Problems Dining philosophers problem (Dijkstra) Models processes competing for exclusive access to a limited number of resources such as I/O devices Readers and writers problem (Courtois et al.

Dining Philosophers ‡ ‡ ‡ ‡ 5 Philosophers around a table and 5 forks Philosophers eat (spaghetti)/think Eating needs 2 forks Pick one fork at a time (first the left fork then the 2 right one and eat) R L 1 3 What problems may occur in this case? 4 0 .

All philosophers picking up their left forks Right forks will not be available Put back the forks and pick the forks again simultaneously Results in Starvation: All the programs continue to run indefinitely without making any progress .

Dining Philosopher: Solution If i=2. LEFT=1 RIGHT=3 .


it will lock the database against writers) ± A reader that finishes reading will decrement rc (when the rc=0 it will unlock the database so that a writer can proceed) ± A writer can have access to the database when rc = 0 and it will lock the database for other readers or writers ± Readers will access the database only when there are no writers (but there may be other readers) .Readers and Writers Problem  Processes compete for reading from and writing to a file  Multiple processes may read the file without any problem  A process can write only if there are no other processes reading or writing  Basic steps on the r/w problem ± rc = reader counter (number of processes currently reading the file) ± A reader who gains access to the database increments rc (when rc=1.

The Readers and Writers Problem Problem? The writer will starve when there is constant supply of readers !!!! Solution is to queue new readers behind the current writer at the expense of reduced concurrency A solution to the readers and writers problem .

and n chairs for waiting customers ‡If there are no customers. then he will sit on the chairs if there is any available. then he will wakeup the barber ‡When a new customer arrives. then the barber sits in his chair and sleeps (as illustrated in the picture) ‡When a new customer arrives and the barber is sleeping. and the barber is busy. .Sleeping Barber Problem ‡ There is one barber. otherwise (when all the chairs are full) he will leave.

.  If a customer arrives when the shop is full.  When the barber invokes cutHair there should be exactly one process invoking getHairCut concurrently.  Barber process should invoke cutHair.Barber Shop Hints Consider the following:  Customer process should invoke a function named getHairCut. he exits.

down(&mutex). up(&mutex). cutHair(). // # customers waiting for service semaphore barbers =0. } } // goto sleep if customers=0 // enter critical region // barber is busy // leave critical region . // To read current value of a semaphore void barber (void) { while(TRUE){ down(&customers). up(&barbers). // barber is idle semaphore mutex = 1.#define CHAIRS 5 typedef int semaphore // #chairs for waiting customers semaphore customers = 0. int waiting =0. waiting = waiting-1.

} else{ up(&mutex).void customer (void) { down(&mutex). } } // No free chairs. down(&barbers). up(&mutex). if (waiting<CHAIRS) { waiting=waiting+1. up(&customers). if necessary // goto sleep. if barber is not free . leave // wake up barber. getHairCut().

Sign up to vote on this title
UsefulNot useful