0% found this document useful (0 votes)
6 views22 pages

Process Synchronization

Chapter 5 discusses process synchronization in operating systems, focusing on the critical-section problem and its solutions. It introduces concepts such as mutual exclusion, progress, and bounded waiting, along with methods like Peterson's solution, mutex locks, and semaphores. The chapter emphasizes the importance of synchronization to maintain data consistency when multiple processes access shared resources concurrently.

Uploaded by

Ch Gulfam
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views22 pages

Process Synchronization

Chapter 5 discusses process synchronization in operating systems, focusing on the critical-section problem and its solutions. It introduces concepts such as mutual exclusion, progress, and bounded waiting, along with methods like Peterson's solution, mutex locks, and semaphores. The chapter emphasizes the importance of synchronization to maintain data consistency when multiple processes access shared resources concurrently.

Uploaded by

Ch Gulfam
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 22

Chapter 5: Process

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 */

while (counter == BUFFER_SIZE) ;


/* do nothing */
buffer[in] = itemp;
in = (in + 1) % BUFFER_SIZE;
counter++;
}
}

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.

Processes Synchronization or Synchronization is the way by which


processes that share the same memory space are managed in an
operating system. It helps maintain the consistency of data by using
variables or hardware so that only one process can make changes to the
shared memory at a time.

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

 General structure of process Pi

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]

 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!

A classic software-based solution to the critical-section problem


May not work correctly on modern computer architecture
However, it provides a good algorithmic description of solving the
critical-section problem

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()

 Definition of the wait() operation

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

You might also like