Process Synchronization

CHAPTER OBJECTIVES
• To introduce the critical-section problem, whose solutions can
be used to ensure the consistency of shared data.
• To present both software and hardware solutions of the
critical-section problem.
• To examine several classical process-synchronization
problems.
• To explore several tools that are used to solve process
synchronization problems.
 The Critical-Section Problem
• Consider a system consisting of n processes {P0, P1, …, Pn−1}.
• Each process has a segment of code, called a critical section,
in which the process may be changing common variables,
updating a table, writing a file, and so on.
• The important feature of the system is that, when one process
is executing in its critical section, no other process is allowed
to execute in its critical section.
• That is, no two processes are executing in their critical
sections at the same time.
• The critical-section problem is to design a protocol that the
processes can use to cooperate.
• Each process must request permission to enter its critical
section.
• The section of code implementing this request is the entry
section.
• The critical section may be followed by an exit section.
• The remaining code is the remainder section.
A solution to the critical-section problem must satisfy the
following three requirements:
• Mutual exclusion. If process Pi is executing in its critical
section, then no other processes can be executing in their
critical sections.
• Progress. If no process is executing in its critical section and
some processes wish to enter their critical sections, then only
those processes that are not executing in their remainder
sections can participate in deciding which will enter its critical
section next, and this selection cannot be postponed
indefinitely.
• Bounded waiting. There exists a bound, or limit, 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.
 Common solutions to the Critical Section
Problem
• Peterson’s solution
• Synchronization Hardware
• Mutex Locks
• Semaphore Solution
 Peterson's Solution
• Classic software-based solution to the critical-section problem
known as Peterson's solution.
• Peterson's solution is restricted to two processes
• The processes are numbered P0 and P1.
• Peterson's solution requires
– int turn;
– boolean flag[2];
• The variable turn indicates whose turn it is to enter its critical
section.
• That is, if turn == i, then process Pi is allowed to execute in its
critical section.
• The flag array is used to indicate if a process is ready to enter
its critical section.
• For example, if flag[i] is true, this value indicates that Pi is
ready to enter its critical section.
• To enter the critical section, process Pi first sets flag[i] to be
true and then sets turn to the value j
 Synchronization Hardware
• Peterson's are not guaranteed to work on modern computer
architectures.
• Hardware features can make any programming task easier
and improve system efficiency.
• The critical-section problem could be solved simply in a single-
processor environment if we could prevent interrupts from
occurring while a shared variable was being modified.
• This solution is not as feasible in a multiprocessor
environment. Disabling interrupts on a multiprocessor can be
time consuming.
Two commonly used Hardware Instructions

• TestandSet()
• Swap()
 test_and_set() instruction
• This instruction is used to test & write to the memory location
before setting a value. If process Pi is executing this
instruction, then process Pj has to wait to execute this
instruction.
•
 Swap() instruction
• A global variable (lock) is declared and is initialized to 0.
• The first process that invokes compare_and_swap() will set
lock to 1.
• It will then enter its critical section
• When a process exits its critical section, it sets lock back to 0.
• Later allows another process to enter its critical section.
 Mutex Locks
• The hardware-based solutions are complicated and
inaccessible to programmers.
• Instead, operating-systems designers build software tools to
solve the critical-section problem.
• The simplest of these tools is the mutex lock (mutual
exclusion).
• A process must acquire the lock before entering a critical
section; it releases the lock when it exits the critical section.
• The acquire() function acquires the lock, and the release()
function releases the lock.
• A mutex lock has a boolean variable available whose value
indicates if the lock is available or not. If the lock is available, a
call to acquire() succeeds.

• The main disadvantage here is that it requires busy waiting.

When a process is in its critical section, any other process that
tries to enter its critical section must call to acquire()
continuously. This type of mutex lock is called as spinlock.
 Semaphores
• A semaphore S is a non-negative integer variable which is
shared between threads.
• Semaphore value is accessible through wait() and signal()
operations.
• When one process modifies the semaphore value, no other
process can simultaneously modify that same semaphore
value.
• wait() operation - It decrements the value of Semaphore S.

• signal() operation – It increments the value of Semaphore S.

 Types of Semaphores

• Binary Semaphore
• Counting Semaphore
 Binary Semaphore
• A Semaphore whose variable is allowed to take only 0 & 1 is
called Binary Semaphore . 0 – busy , 1 – free
• Binary Semaphore are also called as mutex locks, as they
provide mutual exclusion.
 Counting Semaphore
• Used to control access to the given resource which consists of
finite number of instances (copies).
• First the semaphore initialized to the no. of resource
available.
• Each process that wishes to use a resource perform a wait()
operation on the semaphore (decrement the count)
• When a process exit from a critical section, it performs signal()
operation (increment the count)
 Classic Problems of Synchronization
• There are number of synchronization problems as examples.
• We will discuss following problems as an example.
– The Bounded-Buffer (Producer-Consumer) Problem
– The Readers–Writers Problem
– The Dining-Philosophers Problem
Bounded-Buffer (Producer-Consumer) Problem
• Here mutex, empty and full are semaphores
• Mutex is initialized to 1
• Empty is initialized to n
• Full is initialized to 0
• After the item is produced, wait operation is executed on
empty. This indicates the empty space has decreased by 1.
Wait operation is executed on mutex also so that consumer
process should not interfere.
• After the item is put in the buffer, signal operation is carried
out on mutex and full. This indicates that consumer process
can now act
• The wait operation is executed on full. This indicates that item
in the buffer have decreased by 1
• Then the wait operation is executed on mutex so that
producer process should not interfere.
• The item is removed from buffer then signal operation is
executed on mutex and empty.
• Consumer process can act now.
The Readers–Writers Problem
 The Dining-Philosophers Problem
• Consider five philosophers who spend their lives thinking and
eating.
• The philosophers share a circular table surrounded by five
chairs, each belonging to one philosopher.
• In the center of the table is a bowl of rice, and the table is laid
with five single chopsticks.
• When a philosopher gets hungry, tries to pick up the two
chopsticks that are closest to them.
• They cannot pick up a chopstick that is already in the hand of a
neighbor.
• When they finished eating, they put down both chopsticks and
starts thinking again.
One simple solution is to represent each chopstick with a semaphore.
A philosopher tries to grab a chopstick by executing a wait()
operation on that semaphore. They release chopsticks by executing
the signal() operation on the appropriate semaphores.
 Monitors

Semaphores can result in timing errors that are difficult to

detect. To overcome these errors monitors are used for
achieving process synchronization.
The Monitor is a collection of variables, data structures and
procedures that operates on those variables.
• The procedures defined within a monitor can access only
those variables declared within the monitor.
• The variables of the monitor can be accessed only the
procedures within the monitor.
• The monitor ensures that only one process at a time can be
active within the monitor.