OS Chap 5 Slides
OS Chap 5 Slides
OS Chap 5 Slides
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
Semaphores
Classic Problems of Synchronization
Monitors
Synchronization Examples
Alternative Approaches
Operating System Concepts – 9th Edition 5.2 Silberschatz, Galvin and Gagne ©2013
Objectives
To introduce the critical-section problem, whose solutions can be
used to ensure the consistency of shared data
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
Operating System Concepts – 9th Edition 5.4 Silberschatz, Galvin and Gagne ©2013
Producer and Consumer
The producer and consumer share data structure ‘buffer’ and use
other variables shown below:
Operating System Concepts – 9th Edition 5.5 Silberschatz, Galvin and Gagne ©2013
Producer
while (true) {
/* produce an item in next produced */
while (counter == BUFFER_SIZE) ;/* do nothing */
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE;
counter++;
}
Operating System Concepts – 9th Edition 5.6 Silberschatz, Galvin and Gagne ©2013
Consumer
while (true) {
while (counter == 0); /* do nothing */
next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter--;
/* consume the item in next consumed */
}
Operating System Concepts – 9th Edition 5.7 Silberschatz, Galvin and Gagne ©2013
Race Condition
1. counter++ could be implemented as
a) register1 = counter
b) register1 = register1 + 1
c) counter = register1
a) register2 = counter
b) register2 = register2 - 1
c) counter = register2
Operating System Concepts – 9th Edition 5.8 Silberschatz, Galvin and Gagne ©2013
Race Condition
Both producer and consumer routines may not execute properly if
executed concurrently.
Operating System Concepts – 9th Edition 5.9 Silberschatz, Galvin and Gagne ©2013
Race Condition
Consider this execution interleaving with “ count = 5” initially:
Operating System Concepts – 9th Edition 5.10 Silberschatz, Galvin and Gagne ©2013
Race Condition
Operating System Concepts – 9th Edition 5.11 Silberschatz, Galvin and Gagne ©2013
Race Condition Real Life Example
Concurrent transactions in
A Banking Systems
Airline Reservation System
Operating System Concepts – 9th Edition 5.12 Silberschatz, Galvin and Gagne ©2013
Race Condition in Banking Systems
Operating System Concepts – 9th Edition 5.13 Silberschatz, Galvin and Gagne ©2013
Race Condition in Banking Systems
Operating System Concepts – 9th Edition 5.14 Silberschatz, Galvin and Gagne ©2013
Race Condition in Banking Systems
If the transactions are allowed to interleave
Check Deposit:
» MOV A, Balance // A = 50,000
» ADD A, Deposited // A = 60,000
ATM Withdrawal:
» MOV B, Balance // B = 50,000
» SUB B, Withdrawn // B = 45,000
Check Deposit:
» MOV Balance, A // Balance = 60,000
ATM Withdrawal:
» MOV Balance, B // Balance = 45,000
Operating System Concepts – 9th Edition 5.15 Silberschatz, Galvin and Gagne ©2013
Race Condition in Banking Systems
Operating System Concepts – 9th Edition 5.16 Silberschatz, Galvin and Gagne ©2013
Critical Section Problem
Critical Section: A piece of code in a cooperating process in
which the process may updates shared data (variable, file,
database, etc.).
Operating System Concepts – 9th Edition 5.17 Silberschatz, Galvin and Gagne ©2013
Critical Section Problem
Operating System Concepts – 9th Edition 5.18 Silberschatz, Galvin and Gagne ©2013
Critical Section Problem
So each process must first request permission to enter its
critical section.
Operating System Concepts – 9th Edition 5.19 Silberschatz, Galvin and Gagne ©2013
Critical Section
General structure of process pi is
Operating System Concepts – 9th Edition 5.20 Silberschatz, Galvin and Gagne ©2013
Critical-Section Problem: An Example
A kernel data structure that maintains a list of all open files in the
system.
This list must be modified when a new file is opened or closed (adding
the file to the list or removing it from the list)
Operating System Concepts – 9th Edition 5.21 Silberschatz, Galvin and Gagne ©2013
Critical-Section Solutions
There can be three kinds of solution to the critical section problem:
Operating System Concepts – 9th Edition 5.22 Silberschatz, Galvin and Gagne ©2013
Solution to Critical-Section Problem
A solution to the critical section problem must satisfy the following three
requirements:
1. Mutual Exclusion
2. Progress
3. Bounded Waiting
Operating System Concepts – 9th Edition 5.23 Silberschatz, Galvin and Gagne ©2013
Solution to Critical-Section Problem
1. Mutual Exclusion: If process Pi is executing in its critical section, then
Operating System Concepts – 9th Edition 5.24 Silberschatz, Galvin and Gagne ©2013
Solution to Critical-Section Problem
Operating System Concepts – 9th Edition 5.25 Silberschatz, Galvin and Gagne ©2013
Solution to Critical-Section Problem
Two general approaches are used to handle critical sections in
operating systems
1. Pre-emptive kernels
2. Non-preemptive kernels
Operating System Concepts – 9th Edition 5.26 Silberschatz, Galvin and Gagne ©2013
Solution to Critical-Section Problem
Obviously, a nonpreemptive kernel is essentially free from race
conditions on kernel data structures, as only one process is active in the
kernel at a time.
Operating System Concepts – 9th Edition 5.27 Silberschatz, Galvin and Gagne ©2013
Solution: Algorithm # 01 for two Process
The first approach is to let the processes share a common integer variable
turn initialized to 0 or 1.
Operating System Concepts – 9th Edition 5.28 Silberschatz, Galvin and Gagne ©2013
Solution: Algorithm # 01 for two Process
PJ Pi
Operating System Concepts – 9th Edition 5.29 Silberschatz, Galvin and Gagne ©2013
Solution: Algorithm # 02 for two Process
Operating System Concepts – 9th Edition 5.30 Silberschatz, Galvin and Gagne ©2013
Solution: Algorithm # 02 for two Process
The structure of process Pi is shown
Operating System Concepts – 9th Edition 5.31 Silberschatz, Galvin and Gagne ©2013
Algorithm # 03: Peterson’s Solution for two
process
The variable turn indicates whose turn it is to enter the 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 the critical section.
flag[i] = true implies that process Pi is ready.
Operating System Concepts – 9th Edition 5.32 Silberschatz, Galvin and Gagne ©2013
Algorithm # 03: Peterson’s Solution for two process
Operating System Concepts – 9th Edition 5.33 Silberschatz, Galvin and Gagne ©2013
N-Process Critical Section Problem
Consider a system of n processes (Po, 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.
Operating System Concepts – 9th Edition 5.34 Silberschatz, Galvin and Gagne ©2013
Bakery algorithm
The bakery algorithm is due to Leslie Lamport and is based on
a scheduling algorithm commonly used in bakeries, ice-cream
stores, and other locations where order must be made out of
chaos
Operating System Concepts – 9th Edition 5.35 Silberschatz, Galvin and Gagne ©2013
Bakery algorithm
Unfortunately, the bakery algorithm cannot guarantee that two
processes (customers) will not receive the same number.
Operating System Concepts – 9th Edition 5.36 Silberschatz, Galvin and Gagne ©2013
Bakery algorithm
Since process names are unique and totally ordered. The
common data structures are:
boolean choosing [n];
int number[n];
Operating System Concepts – 9th Edition 5.37 Silberschatz, Galvin and Gagne ©2013
Bakery algorithm
Operating System Concepts – 9th Edition 5.38 Silberschatz, Galvin and Gagne ©2013
Working of Bakery algorithm
There are five processes, P0 through P4. P1’s number is 0 because it is not
interested in getting into its critical section at this time.
All other processes are interested in entering their critical sections and
have chosen non-zero numbers by using the max() function in their entry
sections.
Operating System Concepts – 9th Edition 5.39 Silberschatz, Galvin and Gagne ©2013
Working of Bakery algorithm
Operating System Concepts – 9th Edition 5.40 Silberschatz, Galvin and Gagne ©2013
Synchronization Hardware
Many systems provide hardware support for critical section code
Operating System Concepts – 9th Edition 5.41 Silberschatz, Galvin and Gagne ©2013
Solution to Critical-section Problem Using Locks
do {
acquire lock
critical section
release lock
remainder section
} while (TRUE);
Operating System Concepts – 9th Edition 5.42 Silberschatz, Galvin and Gagne ©2013
test_and_set Instruction
Definition:
Operating System Concepts – 9th Edition 5.43 Silberschatz, Galvin and Gagne ©2013
Solution using test_and_set()
Shared boolean variable lock, initialized to FALSE
Solution:
do {
while (test_and_set(&lock))
; /* do nothing */
/* critical section */
lock = false;
/* remainder section */
} while (true);
Operating System Concepts – 9th Edition 5.44 Silberschatz, Galvin and Gagne ©2013
compare_and_swap Instruction
Definition:
Operating System Concepts – 9th Edition 5.45 Silberschatz, Galvin and Gagne ©2013
Solution using compare_and_swap
Shared Boolean variable lock initialized to FALSE; Each process has a local Boolean variable key
Solution:
do {
while (compare_and_swap(&lock, 0, 1) != 0)
; /* do nothing */
/* critical section */
lock = 0;
/* remainder section */
} while (true);
Operating System Concepts – 9th Edition 5.46 Silberschatz, Galvin and Gagne ©2013
Bounded-waiting Mutual Exclusion with test_and_set
do {
waiting[i] = true;
key = true;
while (waiting[i] && key)
key = test_and_set(&lock);
waiting[i] = false;
/* critical section */
j = (i + 1) % n;
while ((j != i) && !waiting[j])
j = (j + 1) % n;
if (j == i)
lock = false;
else
waiting[j] = false;
/* remainder section */
} while (true);
Operating System Concepts – 9th Edition 5.47 Silberschatz, Galvin and Gagne ©2013
Mutex Locks
Previous solutions are complicated and generally inaccessible to application
programmers
OS designers build software tools to solve critical section problem
Simplest is mutex lock
Product critical regions with it by first acquire() a lock then release() it
Boolean variable indicating if lock is available or not
Operating System Concepts – 9th Edition 5.48 Silberschatz, Galvin and Gagne ©2013
acquire() and release()
acquire() {
while (!available)
; /* busy wait */
available = false;;
}
release() {
available = true;
}
do {
acquire lock
critical section
release lock
remainder section
} while (true);
Operating System Concepts – 9th Edition 5.49 Silberschatz, Galvin and Gagne ©2013
Semaphore
Synchronization tool that does not require busy waiting
Semaphore S – integer variable
Two standard operations modify S: wait() and signal()
Originally called P() and V()
Less complicated
Can only be accessed via two indivisible (atomic) operations
wait (S) {
while (S <= 0)
; // busy wait
S--;
}
signal (S) {
S++;
}
Operating System Concepts – 9th Edition 5.50 Silberschatz, Galvin and Gagne ©2013
Semaphore Usage
Counting semaphore – integer value can range over an unrestricted domain
Binary semaphore – integer value can range only between 0 and 1
Then a mutex lock
Can implement a counting semaphore S as a binary semaphore
Can solve various synchronization problems
Consider P1 and P2 that require S1 to happen before S2
P1:
S1;
signal(synch);
P2:
wait(synch);
S2;
Operating System Concepts – 9th Edition 5.51 Silberschatz, Galvin and Gagne ©2013
Semaphore Implementation
Must guarantee that no two processes can execute wait() and signal() on the same semaphore at
the same time
Thus, 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 section 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
Operating System Concepts – 9th Edition 5.52 Silberschatz, Galvin and Gagne ©2013
Semaphore Implementation
with no Busy waiting
Two operations:
block – place the process invoking the operation on the appropriate waiting queue
wakeup – remove one of processes in the waiting queue and place it in the ready queue
Operating System Concepts – 9th Edition 5.53 Silberschatz, Galvin and Gagne ©2013
Semaphore Implementation with
no Busy waiting (Cont.)
typedef struct{
int value;
struct process *list;
} semaphore;
wait(semaphore *S) {
S->value--;
if (S->value < 0) {
add this process to S->list;
block();
}
}
signal(semaphore *S) {
S->value++;
if (S->value <= 0) {
remove a process P from S->list;
wakeup(P);
}
}
Operating System Concepts – 9th Edition 5.54 Silberschatz, Galvin and Gagne ©2013
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);
Operating System Concepts – 9th Edition 5.55 Silberschatz, Galvin and Gagne ©2013
Classical Problems of Synchronization
Classical problems used to test newly-proposed synchronization schemes
Bounded-Buffer Problem
Dining-Philosophers Problem
Operating System Concepts – 9th Edition 5.56 Silberschatz, Galvin and Gagne ©2013
Bounded-Buffer Problem
n buffers, each can hold one item
Operating System Concepts – 9th Edition 5.57 Silberschatz, Galvin and Gagne ©2013
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);
Operating System Concepts – 9th Edition 5.58 Silberschatz, Galvin and Gagne ©2013
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);
Operating System Concepts – 9th Edition 5.59 Silberschatz, Galvin and Gagne ©2013
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
Several variations of how readers and writers are treated – all involve priorities
Shared Data
Data set
Semaphore rw_mutex initialized to 1
Semaphore mutex initialized to 1
Integer read_count initialized to 0
Operating System Concepts – 9th Edition 5.60 Silberschatz, Galvin and Gagne ©2013
Readers-Writers Problem (Cont.)
The structure of a writer process
do {
wait(rw_mutex);
...
/* writing is performed */
...
signal(rw_mutex);
} while (true);
Operating System Concepts – 9th Edition 5.61 Silberschatz, Galvin and Gagne ©2013
Readers-Writers Problem (Cont.)
The structure of a reader process
do {
wait(mutex);
read count++;
if (read_count == 1)
wait(rw_mutex);
signal(mutex);
...
/* reading is performed */
...
wait(mutex);
read count--;
if (read_count == 0)
signal(rw_mutex);
signal(mutex);
} while (true);
Operating System Concepts – 9th Edition 5.62 Silberschatz, Galvin and Gagne ©2013
Readers-Writers Problem Variations
First variation – no reader kept waiting unless writer has permission to use shared object
Operating System Concepts – 9th Edition 5.63 Silberschatz, Galvin and Gagne ©2013
Dining-Philosophers Problem
Operating System Concepts – 9th Edition 5.64 Silberschatz, Galvin and Gagne ©2013
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);
Operating System Concepts – 9th Edition 5.65 Silberschatz, Galvin and Gagne ©2013
Problems with Semaphores
Incorrect use of semaphore operations:
Operating System Concepts – 9th Edition 5.66 Silberschatz, Galvin and Gagne ©2013
Monitors
A high-level abstraction that provides a convenient and effective mechanism for
process synchronization
Abstract data type, internal variables only accessible by code within the procedure
Only one process may be active within the monitor at a time
But not powerful enough to model some synchronization schemes
monitor monitor-name
{
// shared variable declarations
procedure P1 (…) { …. }
Operating System Concepts – 9th Edition 5.67 Silberschatz, Galvin and Gagne ©2013
Schematic view of a Monitor
Operating System Concepts – 9th Edition 5.68 Silberschatz, Galvin and Gagne ©2013
Condition Variables
condition x, y;
Operating System Concepts – 9th Edition 5.69 Silberschatz, Galvin and Gagne ©2013
Monitor with Condition Variables
Operating System Concepts – 9th Edition 5.70 Silberschatz, Galvin and Gagne ©2013
Condition Variables Choices
If process P invokes x.signal(), with Q in x.wait() state, what should happen next?
If Q is resumed, then P must wait
Options include
Signal and wait – P waits until Q leaves monitor or waits for another condition
Signal and continue – Q waits until P leaves the monitor or waits for another condition
Operating System Concepts – 9th Edition 5.71 Silberschatz, Galvin and Gagne ©2013
Solution to Dining Philosophers
monitor DiningPhilosophers
{
enum { THINKING; HUNGRY, EATING) state [5] ;
condition self [5];
Operating System Concepts – 9th Edition 5.72 Silberschatz, Galvin and Gagne ©2013
Solution to Dining Philosophers (Cont.)
initialization_code() {
for (int i = 0; i < 5; i++)
state[i] = THINKING;
}
}
Operating System Concepts – 9th Edition 5.73 Silberschatz, Galvin and Gagne ©2013
Solution to Dining Philosophers (Cont.)
Each philosopher i invokes the operations pickup() and putdown() in the following sequence:
DiningPhilosophers.pickup(i);
EAT
DiningPhilosophers.putdown(i);
Operating System Concepts – 9th Edition 5.74 Silberschatz, Galvin and Gagne ©2013
Monitor Implementation Using Semaphores
Variables
semaphore mutex; // (initially = 1)
semaphore next; // (initially = 0)
int next_count = 0;
wait(mutex);
…
body of F;
…
if (next_count > 0)
signal(next)
else
signal(mutex);
Operating System Concepts – 9th Edition 5.75 Silberschatz, Galvin and Gagne ©2013
Monitor Implementation – Condition Variables
For each condition variable x, we have:
x_count++;
if (next_count > 0)
signal(next);
else
signal(mutex);
wait(x_sem);
x_count--;
Operating System Concepts – 9th Edition 5.76 Silberschatz, Galvin and Gagne ©2013
Monitor Implementation (Cont.)
The operation x.signal can be implemented as:
if (x_count > 0) {
next_count++;
signal(x_sem);
wait(next);
next_count--;
}
Operating System Concepts – 9th Edition 5.77 Silberschatz, Galvin and Gagne ©2013
Resuming Processes within a Monitor
If several processes queued on condition x, and x.signal() executed, which should be resumed?
Operating System Concepts – 9th Edition 5.78 Silberschatz, Galvin and Gagne ©2013
A Monitor to Allocate Single Resource
monitor ResourceAllocator
{
boolean busy;
condition x;
void acquire(int time) {
if (busy)
x.wait(time);
busy = TRUE;
}
void release() {
busy = FALSE;
x.signal();
}
initialization code() {
busy = FALSE;
}
}
Operating System Concepts – 9th Edition 5.79 Silberschatz, Galvin and Gagne ©2013
Homework
Write answers to the (Only) even numbered exercise
question from 5.1 to 5.10
Operating System Concepts – 9th Edition 5.80 Silberschatz, Galvin and Gagne ©2013
Homework
Write answers to exercise question from 5.3 to 5.14
Operating System Concepts – 9th Edition 5.81 Silberschatz, Galvin and Gagne ©2013
End of Chapter 5
Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne ©2013