Process Synchronization
Process Synchronization
Synchronization
Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne ©2013
Chapter 5: Process Synchronization
Background
The Critical-Section Problem
Peterson’s Solution
Synchronization Hardware
Mutex Locks
Operating System Concepts – 9th Edition 5.2 Silberschatz, Galvin and Gagne ©2013
Objectives
To present the concept of 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-section problem
To examine several classical process-synchronization
problems
To explore several tools that are used to solve process
synchronization problems
Operating System Concepts – 9th Edition 5.3 Silberschatz, Galvin and Gagne ©2013
Background
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:
Suppose that we wanted to provide a solution to the
consumer-producer 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.
Operating System Concepts – 9th Edition 5.4 Silberschatz, Galvin and Gagne ©2013
Producer
int count = 0;
void producer(void)
{
int itemp;
while (true) {
produce_item(itemp);
/* produce an item in next produced */
Operating System Concepts – 9th Edition 5.5 Silberschatz, Galvin and Gagne ©2013
Consumer
void consumer(void)
{
int itemc;
while (true) {
while (counter == 0)
; /* do nothing */
itemc = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter--;
/* consume the item in next consumed */
}
}
Operating System Concepts – 9th Edition 5.6 Silberschatz, Galvin and Gagne ©2013
Race Condition
counter++ could be implemented as Race condition
can take place
register1 = counter
register1 = register1 + 1 when multiple
counter = register1 processes or
counter-- could be implemented as threads operate
on a shared data
register2 = counter
register2 = register2 - 1
counter = register2
Consider this execution interleaving with “count = 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}
A situation like this, 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.
Operating System Concepts – 9th Edition 5.7 Silberschatz, Galvin and Gagne ©2013
Race Condition
A situation 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.
To guard against the race condition , we need to ensure that only one
process at a time be manipulating the shared data (the counter variable in
above examples).
To make such a guarantee, we require that the processes be synchronized
in some way.
Because of data consistency in cooperating processes we need Process
synchronization.
Operating System Concepts – 9th Edition 5.8 Silberschatz, Galvin and Gagne ©2013
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
Operating System Concepts – 9th Edition 5.9 Silberschatz, Galvin and Gagne ©2013
Critical Section
Operating System Concepts – 9th Edition 5.10 Silberschatz, Galvin and Gagne ©2013
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
Operating System Concepts – 9th Edition 5.11 Silberschatz, Galvin and Gagne ©2013
Critical-Section Handling in OS
Two approaches depending on if kernel is preemptive or non-
preemptive
Preemptive – allows preemption of process when running
in kernel mode
Non-preemptive – runs until exits kernel mode, blocks, or
voluntarily yields CPU
Essentially free of race conditions in kernel mode
Operating System Concepts – 9th Edition 5.12 Silberschatz, Galvin and Gagne ©2013
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]
Operating System Concepts – 9th Edition 5.13 Silberschatz, Galvin and Gagne ©2013
Algorithm for Process P0 and P1
P0 P1
while(1) while(1)
{ {
flag[0] = true; flag[1] = true;
turn = 1; turn = 0;
while (turn==1 && while(turn==0 &&
flag[1]==T); flag[0]==T);
critical section critical section
flag[0] = false; flag[1] = false;
remainder section remainder section
} }
Turn = 0 0r 1
P0 P1
Flag= F Flag= F
Operating System Concepts – 9th Edition 5.14 Silberschatz, Galvin and Gagne ©2013
Algorithm for Process P0 and P1
P0 P1
while(1) while(1)
{ {
flag[0] = true; flag[1] = true;
turn = 1; turn = 0;
while (turn==1 && while(turn==0 &&
flag[1]==T); flag[0]==T);
critical section critical section
flag[0] = false; flag[1] = false;
remainder section remainder section
} }
Turn = 0 0r 1
P0 P1
Flag= F Flag= F
Operating System Concepts – 9th Edition 5.15 Silberschatz, Galvin and Gagne ©2013
Algorithm for Process P0 and P1
P0 P1
while(1) while(1)
{ {
flag[0] = true; flag[1] = true;
turn = 1; turn = 0;
while (turn==1 && while(turn==0 &&
flag[1]==T); flag[0]==T);
critical section critical section
flag[0] = false; flag[1] = false;
remainder section remainder section
} }
Turn = 0 0r 1
P0 P1
Flag= F Flag= F
Operating System Concepts – 9th Edition 5.16 Silberschatz, Galvin and Gagne ©2013
Peterson’s Solution (Cont.)
Provable that the three CS requirement are met:
1. Mutual exclusion is preserved
P0 enters CS only if:
either flag[1] = false or turn = 0
2. Progress requirement is satisfied
3. Bounded-waiting requirement is met
Operating System Concepts – 9th Edition 5.17 Silberschatz, Galvin and Gagne ©2013
Mutex Locks
Hardware 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
Operating System Concepts – 9th Edition 5.21 Silberschatz, Galvin and Gagne ©2013
acquire() and release()
acquire() { release() {
while (!available) available = true;
; /* busy wait */ }
available = false;;
}
do {
acquire lock
critical section
release lock
remainder section
} while (true);
Operating System Concepts – 9th Edition 5.22 Silberschatz, Galvin and Gagne ©2013
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()
wait(S) {
while (S <= 0)
; // busy wait
S--;
}
Definition of the signal() operation
signal(S) {
S++;
}
Operating System Concepts – 9th Edition 5.23 Silberschatz, Galvin and Gagne ©2013
Semaphore
wait(S) { signal(S) {
while {(S <= 0)
wait(S) S++;
; //(Sbusy
while wait
<= 0) }
S--;; // busy wait
} S--;
}
do {
Entry section
//critical section
Exit section
//remainder section
} while (true);
S=1
Operating System Concepts – 9th Edition 5.24 Silberschatz, Galvin and Gagne ©2013
Types of Semaphores
Semaphores are of two Types:
• Binary Semaphore: This is also known as a mutex lock, as they
are locks that provide mutual exclusion. It can have only two
values – 0 and 1. Its value is initialized to 1. It is used to
implement the solution of critical section problems with multiple
processes and a single resource.
• Counting Semaphore: Counting semaphores can be used to
control access to a given resource consisting of a finite number of
instances. The semaphore is initialized to the number of resources
available. Its value can range over an unrestricted domain.
Operating System Concepts – 9th Edition 5.25 Silberschatz, Galvin and Gagne ©2013