Unit-3 Process

Synchronization
 • 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-
Objectives section problem.
• To examine several classical process-
synchronization problems.
• To explore several tools that are
used to solve process synchronization
problems
 • Process Synchronization is the coordination of
execution of multiple processes in a multi-process
system to ensure that they access shared
resources in a controlled and predictable manner.
• The main objective of process synchronization is
to ensure that multiple processes access shared
resources without interfering with each other
Process and to prevent the possibility of inconsistent data
due to concurrent access.
Synchronization
• To achieve this, various synchronization
techniques such as semaphores, monitors, and
critical sections are used.
• In a multi-process system, synchronization is
necessary to ensure data consistency and
integrity, and to avoid the risk of deadlocks and
other synchronization problems.
 • When two or more process cooperates
with each other, their order of execution
must be preserved otherwise there can
be conflicts in their execution and
inappropriate outputs can be produced.
• A cooperative process is the one which
can affect the execution of other process
Process or can be affected by the execution of
Synchronization other process. Such processes need to be
synchronized so that their order of
execution can be guaranteed.
• The procedure involved in preserving the
appropriate order of execution of
cooperative processes is known as
Process Synchronization.
 • Processes can execute concurrently
• May be interrupted at any time, partially completing
execution
• Concurrent access to shared data may result in data
inconsistency
• Maintaining data consistency requires mechanisms to
ensure the orderly execution of cooperating processes
• Illustration of the problem using producer-consumer
Background problem:

Suppose that we wanted to provide a solution to

the producer-consumer problem that fills all the buffers. We
can do so by having an integer counter that 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)
{
/* produce an item in next produced */

while (counter == BUFFER_SIZE)

/* do nothing */
Producer
buffer[in] = next_produced;

in = (in + 1) % BUFFER_SIZE;

counter++;

}
 while (true) {

while (counter == 0)
/* do nothing */

next_consumed = buffer[out];

Consumer out = (out + 1) % BUFFER_SIZE;

counter--;

/* consume the item in next

consumed */

}
 • The Producer-Consumer problem is a classical
multi-process synchronization problem, that is
we are trying to achieve synchronization
between more than one process.

• There is one Producer in the producer-consumer

Producer-Consumer problem, Producer is producing some items,
whereas there is one Consumer that is
Problem consuming the items produced by the Producer.
The same memory buffer is shared by both
producers and consumers which is of fixed-size.

• The task of the Producer is to produce the item,

put it into the memory buffer, and again start
producing items. Whereas the task of the
Consumer is to consume the item from the
memory buffer.
 • The producer should produce data only when
the buffer is not full. In case it is found that the
buffer is full, the producer is not allowed to
store any data into the memory buffer.

Let's understand • Data can only be consumed by the consumer if

what is the and only if the memory buffer is not empty. In
case it is found that the buffer is empty, the
problem? consumer is not allowed to use any data from
the memory buffer.

• Accessing memory buffer should not be

allowed to producer and consumer at the same
time.
  (Process-A) counter++ could be implemented
as
register1 = counter
register1 = register1 + 1
counter = register1

Race Condition  (Process-B) counter-- could be implemented

as
register2 = counter
register2 = register2 - 1
counter = register2
  Process-A and Process-B Concurrent Execution

Consider this execution interleaving with “count = 5” initially:

Race Condition S0: producer execute register1 = counter {register1 = 5}

S1: consumer execute register2 = counter {register2 = 5}
S2: producer execute register1 = register1 + 1 {register1 = 6}
S3: consumer execute register2 = register2 – 1 {register2 = 4}
S4: producer execute counter = register1 {counter = 6 }
S5: consumer execute counter = register2
 A situation like, where several
processes access and manipulate
the same data concurrently and
the outcome of the execution
depends on the particular order
in which the access takes place, is
called a Race Condition.
Race condition A situation like, where several
processes access and manipulate
the same data concurrently and
the outcome of the execution
depends on the particular order
in which the access takes place, is
called a Race Condition.
 • 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
Critical Section one process is executing in its critical section, no
Problem 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.
 • 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.

Critical Section • When one process in critical section, no other

Problem 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
 • General structure of a process:
do {
entry section

critical section
Critical section
problem
exit section

remainder section

} while (true);
 • A solution to the critical-section problem must
satisfy the following three requirements:
Mutual Exclusion : “Only one process should
execute in its critical section”. If process Pi is
executing in its critical section, then no other
Solution to Critical processes can be executing in their critical
sections.
Section Problem
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
 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
Solution to Critical section and before that request is granted

Section Problem Assume that each process executes at a nonzero

speed

No assumption concerning relative speed of the n

processes
 Two approaches depending on if kernel is
preemptive or non-preemptive

Preemptive – allows preemption of process

when running in kernel mode
Critical section
handling in OS Non-preemptive – runs until exits kernel
mode, blocks, or voluntarily yields
CPU
Essentially free of race conditions in kernel
mode
 Case:1 (Strict Alteration mode)
P0 P1
while (TRUE) while (TRUE)
{ {
while (turn != 0); while (turn != 1);

//do nothing if true //do nothing if true

critical_ section(); critical_ section();
turn = 1 ; turn = 0 ;
} }

reminder section(); reminder section();

  Each process give the turn to each other

 This solution achieve Mutual exclusion but no

progress

 Solution of Critical Section problem must

Case:1 (Strict satisfy three condition:
Alteration Mode)
Mutual Exclusion: Yes

Progress : No

Bounded Wait : -
 Case:2
P0 P1
while (1) while (1)

{ {

flag[0]=true; flag[1]=true;
while (flag[1] == true); while (flag[0] == true);

//do nothing if true //do nothing if true

critical_ region();
critical_ region();

flag[0] = false ;
flag[0] = false ;
noncritical_ region();
noncritical_ region();
}
}
  Initially flag[0]=flag[1]=false

 Each process give the turn to each other

 Solution of Critical Section problem must satisfy three

condition:
Mutual Exclusion: Yes

Case:2 Progress : No

Bounded Wait : -

 This solution achieve Mutual exclusion but no progress

 Deadlock may occur when if flag[0]=flag[1]=true

 • a classic software-based solution to the
critical-section problem known as
Peterson’s solution.
• we present the solution because it
provides a good algorithmic description
of solving the critical-section problem
and illustrates some of the complexities
Case: 3 Peterson’s involved in designing software that
Solution addresses the requirements of mutual
exclusion, progress, and bounded
waiting.
• Peterson’s solution is restricted to two
processes that alternate execution
between their critical sections and
remainder sections.
 Case:3 (Peterson’s Solution)
P0 P1
While(1) While(1)
{ {
i=0; j=1;
flag[i] = true;
flag[j] = true;
turn = j;
turn = i;
while (flag[j]== true &&
while (flag[i]==true &&
turn == j) ;
//do nothing if true turn == i) ;
critical section() ; //do nothing if true
flag[i] = false; critical section () ;
flag[j] = false;
reminder section() reminder section()
} }
 • Solution of Critical Section problem must
satisfy three condition:

- Mutual Exclusion: Yes

- Progress : Yes
- Bounded Wait : Yes
Case:3
• - Best solution for 2 process
- this solution achieve Mutual exclusion and
progress
• - also satisfy bounded wait
- Software based solution
 • Many systems provide hardware
support for implementing the critical
section code.
• All solutions below based on idea of
locking
• Protecting critical regions via locks
Synchronization
• Uniprocessors – could disable
Hardware interrupts
• Currently running code would
execute without preemption
• Generally too inefficient on
multiprocessor systems
• Operating systems using this
not broadly scalable
 • Uniprocessor:

• Process Pi

Disable interrupts
<critical
section>

Synchronization Enable interrupts

<reminder section>

Hardware
• Its very time consuming and decrease the efficiency
of system
• Also not practical solution
• Not feasible for multi-processor
environment because disable the
interrupt is time consuming task and
not desirable
 • Modern machines provide special atomic
Synchronization hardware instructions

Hardware • Atomic = non-interruptible

• Either test memory word and set value
• Or swap contents of two memory words
 • Test and Set instruction are simple hardware
instructions that solve the critical section
1. test_and_set problem by providing mutual exclusion in an
easy and efficient way in a multiprocessor
Instruction environment.
1. Mutual Exclusion using test_and_set()
Shared Boolean variable lock, initialized to FALSE:
Test and Set Function: Process P1 and P2 want to access CS

boolean test_and_set (boolean *lock) Boolean lock = false;

{ //Entry Section

boolean temp = *lock; do {

while (test_and_set(&lock)) ;
lock = TRUE;
return temp:
/* do nothing */

}
<critical section>

lock = false;

Lock = F, T, F <remainder section>

} while (true);
Temp = F, T, F
 • For Hardware designers, implementing atomic
TestAndSet() instruction on multiprocessor is
not a trivial (easy) task.

Disadvantages of • Hardware-base solution are complicated for

Hardware solution application programmer to use.

• To overcome this difficulty, we can use a

synchronization tool called semaphores.
 • Many systems provide hardware support for
implementing the critical section code.
• All solutions are based on idea of locking
• Protecting critical regions via locks
(MUTEX)
• Code:
do {

MUTEX Locks Acquire_lock

(Spin Lock) critical section

Release_lock
remainder section
} while (TRUE);
• Problem: Busy Waiting
• This types of the lock also known as “SPIN
LOCK”
 • Busy waiting : when a process is in a c.s only
other process that tries to enter in c.s must loop
Busy Waiting continuously in its entry code.
 • Mutex locks, as we mentioned earlier, are
generally considered the simplest of
synchronization tools.
Semaphores • Semaphore is a more robust tool that can
behave similarly to a mutex lock but can also
provide more sophisticated ways for
processes to synchronize their activities.
 • Synchronization tool that provides more sophisticated
ways (than Mutex locks) for process to synchronize
their activities.
• Semaphore S – integer variable, that apart from
initialization is accessed only through two standard
atomic operation.
• S=0 means busy and S=1 means free.
• Can only be accessed via two indivisible (atomic)
operations
• wait() and signal()
Semaphore • 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++;
}
 • Modification of the integer value of the

Semaphore semaphore in the wait and signal operation

must be executed individually, only one
process can be modify same semaphore value.
 • 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

Semaphore S2
Create a semaphore “semaphore” initialized to 0
Usage P1:
S1;
signal(semaphore);
P2:
wait(semaphore);
S2;
• Can implement a counting semaphore S as a binary
semaphore
Producer consumer using semaphores

• Buffer = 3
• Full & Empty variable define buffer
status
• Mutex Lock ( 1 for free, 0 for occupied)
• Semaphore S
 int signal(int s)
int
mutex=1,full=0,empty=3,x {
=0; return(++s);
}
int wait(int s)
{ void consumer()
return(--s); {
Producer } mutex=wait(mutex);

consumer
full=wait(full);
void producer() empty=signal(empty);

using {
mutex=wait(mutex);
printf("\n consumer
consumes

semaphores full=signal(full);
empty=wait(empty); x--;
item%d",x);

x++; mutex=signal(mutex);
printf("\nproducer }
produces the
item%d",x);

mutex=signal(mutex);
}
 • Must guarantee that no two processes can execute
the wait() and signal() on the same
semaphore at the same time

• Thus, the implementation becomes the critical

section problem where the wait and signal
code are placed in the critical section
• Could now have busy waiting in critical
Semaphore section implementation

Implementation • But implementation code is short

• Little busy waiting if critical section
rarely occupied

• Note that applications may spend lots of time in

critical sections and therefore this is not a good
solution
 Classical • Classical problems used to test newly-proposed
synchronization schemes
Problems of • Bounded-Buffer Problem
• Readers and Writers Problem
Synchronization • Dining-Philosophers Problem
 • n buffers, each can hold one item

Bounded-Buffer • Semaphore mutex initialized to the value 1

• Semaphore full initialized to the value 0
Problem • Semaphore empty initialized to the value n
 Bounded Buffer Problem (Cont.)
• 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);
 Bounded Buffer Problem (Cont.)
 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);
 • 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

Readers- same time

• Only one single writer can access the shared

Writers data at the same time

• Several variations of how readers and writers are
Problem considered – all involve some form of priorities
• Shared Data
• Data set
• Semaphore write_mutex initialized to 1
• Semaphore read_mutex initialized to 1
• Integer read_count initialized to 0
 Readers-Writers Problem (Cont.)
• The structure of a writer process

do {
wait(write_mutex);
...
/* writing is performed */
...
signal(write_mutex);
} while (true);
 Readers-Writers Problem (Cont.)
• The structure of a reader process
do {
wait(read_mutex);
read_count++;
if (read_count == 1)
wait(write_mutex);
signal(read_mutex);
...
/* reading is performed */
...
wait(read_mutex);
read count--;
if (read_count == 0)
signal(write_mutex);
signal(read_mutex);
} while (true);
 • First variation – no reader kept waiting unless
writer has permission to use shared object

Readers- • Second variation – once writer is ready, it

Writers performs the write As Soon As Possible (ASAP)

Problem • Both may have starvation leading to even more

variations
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
 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?
 • Deadlock handling
• Allow at most 4 philosophers to be sitting
simultaneously at the table.
• Allow a philosopher to pick up the forks
Dining- only if both are available (picking must be
done in a critical section.
Philosophers • Use an asymmetric solution -- an odd-

Problem numbered philosopher picks up first the left

chopstick and then the right chopstick. Even-
numbered philosopher picks up first the
Algorithm right chopstick and then the left chopstick.

(Cont.)
 End of Unit 3

Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne ©2013