IPC

Critical Section
Problem

• Consider system of n processes {p0, p1, … pn-1}

• Each process has critical section segment of code
• Process may be changing common variables,
updating table, writing file, etc
• When one process in critical section, no other
may be in its critical section
• Critical section problem is to design protocol to solve
this
• Each process must ask permission to enter critical
section in entry section, may follow critical section
with exit section, then remainder section
Solution to Critical-Section
Problem
1. Mutual Exclusion - If process Pi is executing in its critical section, then no other
processes can be executing in their critical sections
2. Progress - If no process is executing in its critical section and there exist some processes
that wish to enter their critical section, then the selection of the processes that will enter
the critical section next cannot be postponed indefinitely
3. Bounded Waiting - A bound must exist on the number of times that other processes
are allowed to enter their critical sections after a process has made a request to enter its
critical section and before that request is granted
Assume that each process executes at a nonzero speed
No assumption concerning relative speed of the n processes
Peterson’s Solution

• Good algorithmic description of solving the problem

• Two process solution
• Assume that the load and store machine-language instructions are atomic; that is,
cannot be interrupted
• The two processes share two variables:
• int turn;
• Boolean flag[2]

• The variable turn indicates whose turn it is to enter the critical section
• The flag array is used to indicate if a process is ready to enter the critical section.
flag[i] = true implies that process Pi is ready!
do {
do {
flag[i] = true; flag[j] = true;
turn = j; turn = i;
while (flag[j] && turn = = while (flag[i] && turn = = i);
j);
critical section
critical section flag[j] = false;
flag[i] = false; remainder section
remainder section } while (true);
} while (true);

Mutual exclusion is preserved

Pi enters CS only if:
either flag[j] = false or turn = i
Progress requirement is satisfied, Bounded-waiting requirement is met
Synchronization Hardware
• Many systems provide hardware support for implementing the critical section code.
• All solutions below based on idea of locking
• Protecting critical regions via locks
• Uniprocessors – could disable interrupts
• Currently running code would execute without preemption
• Generally too inefficient on multiprocessor systems
• Operating systems using this not broadly scalable
• Modern machines provide special atomic hardware instructions
• Atomic = non-interruptible
• Either test memory word and set value
• Or swap contents of two memory words
do {
acquire lock
critical section
release lock
remainder section
} while (TRUE);
test_and_s Definition:
Shared Boolean variable lock,
initialized to FALSE

et boolean test_and_set (boolean

*target)
Solution:
do {
Instruction {
while
(test_and_set(&lock)) ;
boolean rv = *target; /* do nothing */
*target = TRUE; /* critical section */

return rv: lock = false;

} /* remainder section
*/
Returns the original value of
passed parameter } while (true);

Set the new value of passed

parameter to “TRUE”.
Mutex Locks
 Previous solutions are complicated and generally
inaccessible to application programmers
 OS designers build software tools to solve critical
section problem
 Simplest is mutex lock
 Protect a critical section by first acquire() a lock
then release() the lock
 Boolean variable indicating if lock is available or not
 Calls to acquire() and release() must be atomic
 Usually implemented via hardware atomic
instructions
 But this solution requires busy waiting
 This lock therefore called a spinlock
 acquire() {
while (!available)
; /* busy wait */
available = false;
}
release() {
available = true;
}
do {
acquire lock
critical section
release lock
remainder section
} while (true);
 Semaphore

• Synchronization tool that provides more sophisticated ways (than

Mutex locks) for process to synchronize their activities.
• Semaphore S – integer variable
• Can only be accessed via two indivisible (atomic) operations
• wait() and signal()
• Originally called P() and V()
• Definition of the wait() operation
wait(S) {
while (S <= 0)
; // busy wait
S--;
}
• Definition of the signal() operation
signal(S) {
S++;
}
• Counting semaphore – integer value can range over an unrestricted domain
• Binary semaphore – integer value can range only between 0 and 1
• Same as a mutex lock
• Can solve various synchronization problems
• Consider P1 and P2 that require S1 to happen before S2
Create a semaphore “synch” initialized to 0
P1:
S1;
signal(synch);
P2:
wait(synch);
S2;
• Can implement a counting semaphore S as a binary semaphore
Implementation with
no Busy waiting
wait(semaphore *S) {
S->value--;
if (S->value < 0) {
add this process to S->list;
block();
}
}

signal(semaphore *S) {
S->value++;
if (S->value <= 0) {
remove a process P from S->list;
wakeup(P);
}
}
Code for producer process
Code for consumer process
The structure of the producer process

do {
...
/* produce an item in
next_produced */
...
wait(empty);
wait(mutex);
...
/* add next produced to
the buffer */
...
signal(mutex);
signal(full);
} while (true);
The structure of the consumer process

Do {
wait(full);
wait(mutex);
...
/* remove an item from buffer to next_consumed */
...
signal(mutex);
signal(empty);
...
/* consume the item in next consumed */
...
} while (true);
Readers-Writers Problem

A data set is shared among a number of concurrent processes

• Readers – only read the data set; they do not perform any updates
• Writers – can both read and write

Problem – allow multiple readers to read at the same time

• Only one single writer can access the shared data at the same time

Several variations of how readers and writers are considered – all involve some form of priorities

Shared Data

• Data set
• Semaphore rw_mutex initialized to 1
• Semaphore mutex initialized to 1
• Integer read_count initialized to 0
Readers-Writers
Problem (Cont.)

• The structure of a writer process

do {
wait(rw_mutex);
...
/* writing is performed
*/
...
signal(rw_mutex);
} while (true);
Readers-Writers
Problem (Cont.)
• The structure of a reader process
do {
wait(mutex);
read_count++;
if (read_count == 1)
wait(rw_mutex);
signal(mutex);
...
/* reading is performed */
...
wait(mutex);
read count--;
if (read_count == 0)
signal(rw_mutex);
signal(mutex);
} while (true);
 Readers-Writers Problem Variations

First variation – no reader kept waiting unless writer

has permission to use shared object
Second variation – once writer is ready, it performs the
write ASAP
Both may have starvation leading to even more
variations
Problem is solved on some systems by kernel providing
reader-writer locks
Dining-Philosophers
Problem
• Philosophers spend their lives alternating thinking and eating
• Don’t interact with their neighbors, occasionally try to pick up 2
chopsticks (one at a time) to eat from bowl
• Need both to eat, then release both when done
• In the case of 5 philosophers
• Shared data
• Bowl of rice (data set)
• Semaphore chopstick [5] initialized to 1
 The structure of Philosopher i:

• do {

Dining- • wait (chopstick[i] );

• wait (chopStick[ (i + 1) % 5] );

Philosophe • // eat
• signal (chopstick[i] );

rs Problem • signal (chopstick[ (i + 1) % 5] );

• // think

Algorithm • } while (TRUE);

What is the problem with this algorithm?

Dining-Philosophers Problem
Algorithm (Cont.)
• Deadlock handling
• Allow at most 4 philosophers to be sitting simultaneously at the table.
• Allow a philosopher to pick up the forks only if both are available (picking
must be done in a critical section.
• Use an asymmetric solution -- an odd-numbered philosopher picks up first
the left chopstick and then the right chopstick. Even-numbered philosopher
picks up first the right chopstick and then the left chopstick.
Problems with
Semaphores

• Incorrect use of semaphore operations:

• signal (mutex) …. wait (mutex)

• wait (mutex) … wait (mutex)

• Omitting of wait (mutex) or signal (mutex)

(or both)

• Deadlock and starvation are possible.

THANK YOU