Module 3 : Process Synchronization

Process Synchronization
• Background
• The Critical-Section Problem
• Peterson’s Solution
• Synchronization Hardware
• Semaphores
• Classic Problems of Synchronization
 Objectives
• To introduce the critical-section problem, solutions for consistency
of shared data

• To present both software and hardware solutions of the critical-

section problem

• To introduce the concept of an atomic transaction and mechanisms

to ensure atomicity
 Background
• Concurrent access to shared data by cooperating processes may
result in data inconsistency
• Requires mechanisms to ensure the orderly execution of
cooperating processes for data consistency
• EX: consumer-producer problem , producer fills the buffer.
integer counter keeps track of the number of full
buffers.
• Initially, counter is set to 0. It is incremented by the producer after
it produces a new buffer and is decremented by the consumer
after it consumes a buffer.
while (true) { Producer
/* produce an item and put in buffer */
while (counter == BUFFER_SIZE) ; // do nothing
buffer [in] = item;
in = (in + 1) % BUFFER_SIZE;
counter++;
}
 Consumer

while (true) {
while (counter == 0) ; // do nothing
item = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter--;
/* consume the item from the buffer */
}
 Race Condition
• counter++ could be implemented as(Producer)
register1 = counter
register1 = register1 + 1
counter = register1
• counter-- could be implemented as (consumer)
register2 = counter
register2 = register2 - 1
count = register2
• Consider this execution interleaving with “counter = 5” initially:
S0: producer execute register1 = counter {register1 = 5}
S1: producer execute register1 = register1 + 1 {register1 = 6}
S2: consumer execute register2 = counter {register2 = 5}
S3: consumer execute register2 = register2 - 1 {register2 = 4}
S4: producer execute counter = register1 {counter = 6 }
S5: consumer execute counter = register2 {counter = 4}
Race Condition :

The outcome of the execution concurrent processes working on same

data depends on the particular order in which the access takes place,
is called a Race Condition

To ensure that only one process manipulating the variable counter at a

time .

Require that the processes be synchronized in some way.

 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
 Critical Section
• General structure of process pi is
 Solution to Critical-Section Problem
A solution to the critical-section problem must satisfy the following
requirements:
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 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
 Peterson’s Solution
• classic software-based solution to critical section problem
• Peterson's solution is restricted to two processes
• Assume that the LOAD and STORE 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 to enter the critical section
• if turn == i, then process Pi is allowed to execute in its critical section
• The flag array used to indicate if a process is ready to enter the critical
section.
• flag[i] = true implies that process Pi is ready to enter Critical section
 Algorithm for Process Pi
do {
flag[i] = TRUE;
turn = j; // if the other process wishes to enter the critical section, it can do
so.
while (flag[j] && turn == j);
critical section
flag[i] = FALSE;
remainder section
} while (TRUE);

• Provable that
1. Mutual exclusion is preserved : turn can be either 0 or 1
2. Progress requirement is satisfied :when process i wishes, process j not in CS , Flag[j]
-> false, Process i allowed
3. Bounded-waiting requirement is met :
 Synchronization Hardware
• Hardware support for critical section code
• critical-section problem solved using a tool-a lock.
• Race conditions are prevented
• A process must acquire a lock before entering a critical section; it
releases the lock when exit CS
• Many modern computer systems provide special hardware
instructions to test and modify the content of a word or to swap
the contents of two words atomically-non-interruptable
 Solution to Critical-section
Problem Using Locks

do {
acquire lock
critical section
release lock
remainder section
} while (TRUE);
 TestAndSet Instruction

• Definition:

boolean TestAndSet (boolean *target)

{
boolean rv = *target;
*target = TRUE;
return rv:
}
 Solution using TestAndSet
• Shared boolean variable lock, initialized to FALSE
• Solution:
do {
while ( TestAndSet (&lock )) ; // do nothing
// critical section
lock = FALSE;
// remainder section
} while (TRUE);

• The TestAndSet () instruction is executed atomically.

• This solution is not as feasible in a multiprocessor environment.
• Disabling interrupts on a multiprocessor - time consuming
 Swap Instruction
• Definition:

void Swap (boolean *a, boolean *b)

{
boolean temp = *a;
*a = *b;
*b = temp:
}
 Solution using Swap
• Shared Boolean variable lock initialized to FALSE; Each process has a local
Boolean variable key
• Solution:
do {
key = TRUE;
while ( key == TRUE)
Swap (&lock, &key );
// critical section
lock = FALSE;
// remainder section
} while (TRUE);

• The algorithms satisfy the mutual-exclusion requirement, they do not satisfy the
bounded-waiting requirement.
 Bounded-waiting
do {
waiting[i] = TRUE;
key = TRUE; boolean waiting[n];
while (waiting[i] && key) boolean lock; initialized to false
key = TestAndSet(&lock);
waiting[i] = FALSE;
Value of key become false only if the TestAndSet () is
// critical section
j = (i + 1) % n;
executed. The first process to execute the TestAndSet
while ((j != i) && !waiting[j]) () will find key== false; all others must wait.
j = (j + 1) % n;
if (j == i)
Progress: a process exiting the critical section either
lock = FALSE;
else
sets lock to false or sets waiting[j] to false. Both allow
waiting[j] = FALSE; a process that is waiting to enter its critical section to
// remainder section proceed.
} while (TRUE);

Bounded-waiting: when a process leaves its CS, it

scans the array waiting in the cyclic ordering (i + 1, i +
2, ... , n 1, 0, ... , i-1). It designates the first process that
is in the entry section (waiting[j] ==true) as the next
one to enter the critical section.

complicated for application programmers to use.

 Semaphore
• Semaphore S – integer variable, accessed only through atomic operations : wait() and signal()
• Originally called P() and V()
• Less complicated
• wait (S) {
while S <= 0 ; // no-op
S--;
}
• signal (S) {
S++;
}
• when one process modifies the semaphore value, no other process can
simultaneously modify that same semaphore value.
• Counting semaphore – Positive integer value
• Binary semaphore – integer value can range only between 0 and 1; can be simpler to implement
• Also known as mutex locks

• Provides mutual exclusion

Semaphore mutex; // initialized to 1
do {
wait (mutex);
// Critical Section
signal (mutex);
// remainder section
} while (TRUE);
 Semaphore Implementation

• Disadvantage - when a process is in its critical section, another process trying

to enter its critical section must loop continuously.

• Busy waiting wastes CPU cycles that some other process might be able to
use productively.
• This type of semaphore is also called spinlock because the process "spins"
while waiting for the lock.
• Modified definitions of the wait() and signal() semaphore operations
 Semaphore Implementation
with no Busy waiting

• Each semaphore – has waiting queue associated to it

• When process executes wait () and finds the semaphore value not positive, it
waits.
• Instead of busy waiting, the process blocks itself.
• The block operation places a process into a waiting queue associated with the
semaphore, and the state of the process is switched to the waiting state.
• The control transferred to the CPU scheduler to select another process to
execute.
• A process that is blocked, waiting on a semaphore S, restarted when some
other process executes a signal() operation.
• The process is restarted by a wakeup () operation, which changes the process
from the waiting state to the ready state.
• The process then placed in the ready queue.
• Implementation of wait: typedef struct
wait(semaphore *S) { {
int value;
S->value--;
struct process *list;
if (S->value < 0) { } semaphore
add this process to S->list;
block(); Two operations:
} } block – place the process invoking the operation
on the appropriate waiting queue
wakeup – remove one of processes in the waiting
• Implementation of signal: queue and place it in the ready queue
signal(semaphore *S) {
S->value++;
if (S->value <= 0) {
remove a process P from S-
>list;
wakeup(P);
}
}
 Deadlock and Starvation
• Deadlock – two or more processes are waiting indefinitely for an event that
can be caused by only one of the waiting processes
• Let S and Q be two semaphores initialized to 1
P0 P1
wait (S); wait (Q);
wait (Q); wait (S);
. .
. .
signal (S); signal (Q);
signal (Q); signal (S);

• Starvation – indefinite blocking

• A process may never be removed from the semaphore queue in which it is suspended
• Priority Inversion – Scheduling problem when lower-priority process holds a
lock needed by higher-priority process
Classical Problems of Synchronization

• Bounded-Buffer Problem
• Readers and Writers Problem
• Dining-Philosophers Problem
 Bounded-Buffer Problem

• pool of n buffers, each can hold one item

• Semaphore mutex initialized to the value 1 ; for mutual
exclusion
• Semaphore full initialized to the value 0
• Semaphore empty initialized to the value n
 Bounded Buffer Problem (Cont.)
• The structure of the producer process
do {
// produce an item in nextp
wait (empty);
wait (mutex);
// add the item to the buffer
signal (mutex);
signal (full);
} while (TRUE);
 Bounded Buffer Problem (Cont.)
• The structure of the consumer process
do {
wait (full);
wait (mutex);
// remove an item from buffer to nextc
signal (mutex);
signal (empty);
// consume the item in nextc
} while (TRUE);
 The Reader Writer problem
● A database to be shared among several concurrent processes

● Some processes read the database, some update the database

● Two processes -Reader process and Writer process

● If two reader processes access the db simultaneously , no adverse

effects will result.

● If writer and reader process accesses the db simultaneously, problem

arises

● To ensure writer process have exclusive access to the db.

● This synchronization problem is called Reader writer problem

 Readers-Writers Problem
1. Motivation
In many shared databases, such as bank balances, or airline seats,
there are two classes of users:
● Readers process-- never modify database.
● Writers process -- read and modify database
In these applications, it should be allowed that
● Many readers at same time.
● Only one writer at same time.
2. Constraints

1. Readers can access database when no writers

2. Writers can access database when no readers or writers
Use a separate semaphore for each constraint
 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 –
1. Allow multiple readers to access the file (R1-R2-R3)
2. When reader process is reading the file no other writer process is
allowed to access the file (R-W)
3. When writer process is writing the file no reader or writer process is
allowed to access the file (W-R) (W-W)
 Contd..

❖ Two semaphores are used here

❖ Semaphore mutex initialized to 1 (controls access to
readcount)
❖ Semaphore wrt initialized to 1 (writer access)
❖ Integer readcount initialized to 0 (how many
processes are reading object)
 Readers-Writers Problem (Cont.)

● The structure of a writer process

Entry Section
do { wait (wrt) ;
// writing is performed
signal (wrt) ; Exit Section

} while (TRUE);
 Readers-Writers Problem (Cont.)
● The structure of a reader process
do {
wait (mutex) ; Entry Section
readcount ++ ;
if (readcount == 1)
wait (wrt) ;
signal (mutex)
Critical Section // reading is performed
Exit Section
wait (mutex) ;
readcount - - ;
if (readcount == 0)
signal (wrt) ;
signal (mutex) ;

} while (TRUE);
Dining-Philosophers Problem
• Philosophers spend their lives 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
 Dining-Philosophers Problem Algorithm
• The structure of Philosopher i:
do {
wait ( chopstick[i] );
wait ( chopStick[ (i + 1) % 5] );
// eat
signal ( chopstick[i] );
signal (chopstick[ (i + 1) % 5] );
// think
} while (TRUE);

• What is the problem with this algorithm?

 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

● Some potential solutions to the problem include:
○ Allow four philosophers to dine at the same time.
( Limited simultaneous processes.)
○ Allow philosophers to pick up chopsticks only when
both are available, in a critical section. ( All or nothing
allocation of critical resources. )
○ Use an asymmetric solution, in which odd philosophers
pick up their left chopstick first and even philosophers
pick up their right chopstick first.