Professional Documents
Culture Documents
ch6 Process Synchronization
ch6 Process Synchronization
Synchronization
Background
The Critical-Section Problem
Peterson’s Solution
Synchronization Hardware
Semaphores
Classic Problems of Synchronization
Monitors
Synchronization Examples
Atomic Transactions
Operating System Concepts – 8th Edition 6.2 Silberschatz, Galvin and Gagne
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 introduce the concept of an atomic transaction and
describe mechanisms to ensure atomicity
Operating System Concepts – 8th Edition 6.3 Silberschatz, Galvin and Gagne
Background
Operating System Concepts – 8th Edition 6.4 Silberschatz, Galvin and Gagne
Producer
while (true) {
Operating System Concepts – 8th Edition 6.5 Silberschatz, Galvin and Gagne
Consumer
while (true) {
while (count == 0)
; // do nothing
nextConsumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
count--;
Operating System Concepts – 8th Edition 6.6 Silberschatz, Galvin and Gagne
Race Condition
count++ could be implemented as
register1 = count
register1 = register1 + 1
count = register1
count-- could be implemented as
register2 = count
register2 = register2 - 1
count = register2
Consider this execution interleaving with “count = 5” initially:
S0: producer execute register1 = count {register1 = 5}
S1: producer execute register1 = register1 + 1
{register1 = 6}
S2: consumer execute register2 = count {register2 = 5}
S3: consumer execute register2 = register2 - 1
{register2 = 4}
S4: producer execute count = register1 {count = 6 }
S5: consumer execute count = register2 {count = 4}
Operating System Concepts – 8th Edition 6.7 Silberschatz, Galvin and Gagne
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 – 8th Edition 6.8 Silberschatz, Galvin and Gagne
Peterson’s Solution
Two process solution
Assume that the LOAD and STORE 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!
Operating System Concepts – 8th Edition 6.9 Silberschatz, Galvin and Gagne
Algorithm for Process Pi
do {
flag[i] = TRUE;
turn = j;
while (flag[j] && turn == j);
critical section
flag[i] = FALSE;
remainder section
} while (TRUE);
Operating System Concepts – 8th Edition 6.10 Silberschatz, Galvin and Gagne
Synchronization Hardware
Many systems provide hardware support for critical
section code
Uniprocessors – could disable interrupts
Currently running code would execute without
preemption
Generally too inefficient on multiprocessor
systems
Operating systems using this not broadly
scalable
Modern machines provide special atomic hardware
instructions
Atomic = non-interruptable
Either test memory word and set value
Or swap contents of two memory words
Operating System Concepts – 8th Edition 6.11 Silberschatz, Galvin and Gagne
Solution to Critical-section Problem Using Locks
do {
acquire lock
critical section
release lock
remainder section
} while (TRUE);
Operating System Concepts – 8th Edition 6.12 Silberschatz, Galvin and Gagne
TestAndndSet Instruction
Definition:
Operating System Concepts – 8th Edition 6.13 Silberschatz, Galvin and Gagne
Solution using TestAndSet
do {
while ( TestAndSet (&lock ))
; // do nothing
// critical section
lock = FALSE;
// remainder section
} while (TRUE);
Operating System Concepts – 8th Edition 6.14 Silberschatz, Galvin and Gagne
Swap Instruction
Definition:
Operating System Concepts – 8th Edition 6.15 Silberschatz, Galvin and Gagne
Solution using Swap
Shared Boolean variable lock initialized to FALSE;
Each process has a local Boolean variable key
Solution:
do {
key = TRUE;
while ( key == TRUE)
Swap (&lock, &key );
// critical section
lock = FALSE;
// remainder section
} while (TRUE);
Operating System Concepts – 8th Edition 6.16 Silberschatz, Galvin and Gagne
Bounded-waiting Mutual Exclusion with TestandSet()
do {
waiting[i] = TRUE;
key = TRUE;
while (waiting[i] && key)
key = TestAndSet(&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 – 8th Edition 6.17 Silberschatz, Galvin and Gagne
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
; // no-op
S--;
}
signal (S) {
S++;
}
Operating System Concepts – 8th Edition 6.18 Silberschatz, Galvin and Gagne
Semaphore as General Synchronization Tool
Operating System Concepts – 8th Edition 6.19 Silberschatz, Galvin and Gagne
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
crtical 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 – 8th Edition 6.20 Silberschatz, Galvin and Gagne
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 – 8th Edition 6.21 Silberschatz, Galvin and Gagne
Semaphore Implementation with no Busy waiting (Cont.)
Implementation of wait:
wait(semaphore *S) {
S->value--;
if (S->value < 0) {
add this process to S->list;
block();
}
}
Implementation of signal:
signal(semaphore *S) {
S->value++;
if (S->value <= 0) {
remove a process P from S->list;
wakeup(P);
}
}
Operating System Concepts – 8th Edition 6.22 Silberschatz, Galvin and Gagne
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);
Starvation – indefinite blocking. A process may never be
removed from the semaphore queue in which it is suspended
Priority Inversion - Scheduling problem when lower-priority
process holds a lock needed by higher-priority process
Operating System Concepts – 8th Edition 6.23 Silberschatz, Galvin and Gagne
Classical Problems of Synchronization
Bounded-Buffer Problem
Readers and Writers Problem
Dining-Philosophers Problem
Operating System Concepts – 8th Edition 6.24 Silberschatz, Galvin and Gagne
Bounded-Buffer Problem
N buffers, each can hold one item
Semaphore mutex initialized to the value 1
Semaphore full initialized to the value 0
Semaphore empty initialized to the value N.
Operating System Concepts – 8th Edition 6.25 Silberschatz, Galvin and Gagne
Bounded Buffer Problem (Cont.)
The structure of the producer process
do {
wait (empty);
wait (mutex);
signal (mutex);
signal (full);
} while (TRUE);
Operating System Concepts – 8th Edition 6.26 Silberschatz, Galvin and Gagne
Bounded Buffer Problem (Cont.)
The structure of the consumer process
do {
wait (full);
wait (mutex);
signal (mutex);
signal (empty);
} while (TRUE);
Operating System Concepts – 8th Edition 6.27 Silberschatz, Galvin and Gagne
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
Shared Data
Data set
Semaphore mutex initialized to 1
Semaphore wrt initialized to 1
Integer readcount initialized to 0
Operating System Concepts – 8th Edition 6.28 Silberschatz, Galvin and Gagne
Readers-Writers Problem (Cont.)
The structure of a writer process
do {
wait (wrt) ;
// writing is performed
signal (wrt) ;
} while (TRUE);
Operating System Concepts – 8th Edition 6.29 Silberschatz, Galvin and Gagne
Readers-Writers Problem (Cont.)
The structure of a reader process
do {
wait (mutex) ;
readcount ++ ;
if (readcount == 1)
wait (wrt) ;
signal (mutex)
// reading is performed
wait (mutex) ;
readcount - - ;
if (readcount == 0)
signal (wrt) ;
signal (mutex) ;
} while (TRUE);
Operating System Concepts – 8th Edition 6.30 Silberschatz, Galvin and Gagne
Dining-Philosophers Problem
Shared data
Bowl of rice (data set)
Semaphore chopstick [5] initialized to 1
Operating System Concepts – 8th Edition 6.31 Silberschatz, Galvin and Gagne
Dining-Philosophers Problem (Cont.)
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 – 8th Edition 6.32 Silberschatz, Galvin and Gagne
Problems with Semaphores
Incorrect use of semaphore operations:
Operating System Concepts – 8th Edition 6.33 Silberschatz, Galvin and Gagne
Monitors
A high-level abstraction that provides a convenient and
effective mechanism for process synchronization
Only one process may be active within the monitor at a
time
monitor monitor-name
{
// shared variable declarations
procedure P1 (…) { …. }
…
Operating System Concepts – 8th Edition 6.34 Silberschatz, Galvin and Gagne
Schematic view of a Monitor
Operating System Concepts – 8th Edition 6.35 Silberschatz, Galvin and Gagne
Condition Variables
condition x, y;
Operating System Concepts – 8th Edition 6.36 Silberschatz, Galvin and Gagne
Monitor with Condition Variables
Operating System Concepts – 8th Edition 6.37 Silberschatz, Galvin and Gagne
Solution to Dining Philosophers
monitor DP
{
enum { THINKING; HUNGRY, EATING) state [5] ;
condition self [5];
Operating System Concepts – 8th Edition 6.38 Silberschatz, Galvin and Gagne
Solution to Dining Philosophers (cont)
initialization_code() {
for (int i = 0; i < 5; i++)
state[i] = THINKING;
}
}
Operating System Concepts – 8th Edition 6.39 Silberschatz, Galvin and Gagne
Solution to Dining Philosophers (cont)
DiningPhilosophters.pickup (i);
EAT
DiningPhilosophers.putdown (i);
Operating System Concepts – 8th Edition 6.40 Silberschatz, Galvin and Gagne
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 – 8th Edition 6.41 Silberschatz, Galvin and Gagne
Monitor Implementation
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 – 8th Edition 6.42 Silberschatz, Galvin and Gagne
Monitor Implementation
The operation x.signal can be implemented as:
if (x-count > 0) {
next_count++;
signal(x_sem);
wait(next);
next_count--;
}
Operating System Concepts – 8th Edition 6.43 Silberschatz, Galvin and Gagne
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 – 8th Edition 6.44 Silberschatz, Galvin and Gagne
Synchronization Examples
Solaris
Windows XP
Linux
Pthreads
Operating System Concepts – 8th Edition 6.45 Silberschatz, Galvin and Gagne
Solaris Synchronization
Implements a variety of locks to support multitasking,
multithreading (including real-time threads), and
multiprocessing
Uses adaptive mutexes for efficiency when protecting data
from short code segments
Uses condition variables and readers-writers locks when
longer sections of code need access to data
Uses turnstiles to order the list of threads waiting to acquire
either an adaptive mutex or reader-writer lock
Operating System Concepts – 8th Edition 6.46 Silberschatz, Galvin and Gagne
Windows XP Synchronization
Uses interrupt masks to protect access to global resources
on uniprocessor systems
Uses spinlocks on multiprocessor systems
Also provides dispatcher objects which may act as either
mutexes and semaphores
Dispatcher objects may also provide events
An event acts much like a condition variable
Operating System Concepts – 8th Edition 6.47 Silberschatz, Galvin and Gagne
Linux Synchronization
Linux:
Prior to kernel Version 2.6, disables interrupts to
implement short critical sections
Version 2.6 and later, fully preemptive
Linux provides:
semaphores
spin locks
Operating System Concepts – 8th Edition 6.48 Silberschatz, Galvin and Gagne
Pthreads Synchronization
Operating System Concepts – 8th Edition 6.49 Silberschatz, Galvin and Gagne
Atomic Transactions
System Model
Log-based Recovery
Checkpoints
Concurrent Atomic Transactions
Operating System Concepts – 8th Edition 6.50 Silberschatz, Galvin and Gagne
System Model
Operating System Concepts – 8th Edition 6.51 Silberschatz, Galvin and Gagne
Types of Storage Media
Operating System Concepts – 8th Edition 6.52 Silberschatz, Galvin and Gagne
Log-Based Recovery
Record to stable storage information about all modifications
by a transaction
Most common is write-ahead logging
Log on stable storage, each log record describes single
transaction write operation, including
Transaction name
Data item name
Old value
New value
<Ti starts> written to log when transaction T i starts
<Ti commits> written when Ti commits
Log entry must reach stable storage before operation
on data occurs
Operating System Concepts – 8th Edition 6.53 Silberschatz, Galvin and Gagne
Log-Based Recovery Algorithm
Using the log, system can handle any volatile memory errors
Undo(Ti) restores value of all data updated by T i
Redo(Ti) sets values of all data in transaction T i to new
values
Undo(Ti) and redo(Ti) must be idempotent
Multiple executions must have the same result as one
execution
If system fails, restore state of all updated data via log
If log contains <Ti starts> without <Ti commits>, undo(Ti)
If log contains <Ti starts> and <Ti commits>, redo(Ti)
Operating System Concepts – 8th Edition 6.54 Silberschatz, Galvin and Gagne
Checkpoints
Log could become long, and recovery could take long
Checkpoints shorten log and recovery time.
Checkpoint scheme:
1. Output all log records currently in volatile storage to
stable storage
2. Output all modified data from volatile to stable storage
3. Output a log record <checkpoint> to the log on stable
storage
Now recovery only includes Ti, such that Ti started
executing before the most recent checkpoint, and all
transactions after Ti All other transactions already on stable
storage
Operating System Concepts – 8th Edition 6.55 Silberschatz, Galvin and Gagne
Concurrent Transactions
Must be equivalent to serial execution – serializability
Could perform all transactions in critical section
Inefficient, too restrictive
Concurrency-control algorithms provide serializability
Operating System Concepts – 8th Edition 6.56 Silberschatz, Galvin and Gagne
Serializability
Consider two data items A and B
Consider Transactions T0 and T1
Execute T0, T1 atomically
Execution sequence called schedule
Atomically executed transaction order called serial schedule
For N transactions, there are N! valid serial schedules
Operating System Concepts – 8th Edition 6.57 Silberschatz, Galvin and Gagne
Schedule 1: T0 then T1
Operating System Concepts – 8th Edition 6.58 Silberschatz, Galvin and Gagne
Nonserial Schedule
Nonserial schedule allows overlapped execute
Resulting execution not necessarily incorrect
Consider schedule S, operations Oi, Oj
Conflict if access same data item, with at least one write
If Oi, Oj consecutive and operations of different transactions
& Oi and Oj don’t conflict
Then S’ with swapped order Oj Oi equivalent to S
If S can become S’ via swapping nonconflicting operations
S is conflict serializable
Operating System Concepts – 8th Edition 6.59 Silberschatz, Galvin and Gagne
Schedule 2: Concurrent Serializable Schedule
Operating System Concepts – 8th Edition 6.60 Silberschatz, Galvin and Gagne
Locking Protocol
Operating System Concepts – 8th Edition 6.61 Silberschatz, Galvin and Gagne
Two-phase Locking Protocol
Generally ensures conflict serializability
Each transaction issues lock and unlock requests in two
phases
Growing – obtaining locks
Shrinking – releasing locks
Does not prevent deadlock
Operating System Concepts – 8th Edition 6.62 Silberschatz, Galvin and Gagne
Timestamp-based Protocols
Select order among transactions in advance – timestamp-
ordering
Transaction Ti associated with timestamp TS(Ti) before Ti
starts
TS(Ti) < TS(Tj) if Ti entered system before T j
TS can be generated from system clock or as logical
counter incremented at each entry of transaction
Timestamps determine serializability order
If TS(Ti) < TS(Tj), system must ensure produced schedule
equivalent to serial schedule where T i appears before Tj
Operating System Concepts – 8th Edition 6.63 Silberschatz, Galvin and Gagne
Timestamp-based Protocol Implementation
Data item Q gets two timestamps
W-timestamp(Q) – largest timestamp of any transaction
that executed write(Q) successfully
R-timestamp(Q) – largest timestamp of successful read(Q)
Updated whenever read(Q) or write(Q) executed
Timestamp-ordering protocol assures any conflicting read
and write executed in timestamp order
Suppose Ti executes read(Q)
If TS(Ti) < W-timestamp(Q), Ti needs to read value of Q
that was already overwritten
read operation rejected and Ti rolled back
If TS(Ti) ≥ W-timestamp(Q)
read executed, R-timestamp(Q) set to max(R-
timestamp(Q), TS(Ti))
Operating System Concepts – 8th Edition 6.64 Silberschatz, Galvin and Gagne
Timestamp-ordering Protocol
Suppose Ti executes write(Q)
If TS(Ti) < R-timestamp(Q), value Q produced by T i was
needed previously and Ti assumed it would never be
produced
Write operation rejected, Ti rolled back
If TS(Ti) < W-tiimestamp(Q), Ti attempting to write
obsolete value of Q
Write operation rejected and Ti rolled back
Otherwise, write executed
Any rolled back transaction Ti is assigned new timestamp
and restarted
Algorithm ensures conflict serializability and freedom from
deadlock
Operating System Concepts – 8th Edition 6.65 Silberschatz, Galvin and Gagne
Schedule Possible Under Timestamp Protocol
Operating System Concepts – 8th Edition 6.66 Silberschatz, Galvin and Gagne
End of Chapter 6