Professional Documents
Culture Documents
New ch6 Updated
New ch6 Updated
Background
The Critical-Section Problem
Peterson’s Solution
Synchronization Hardware
Semaphores
Classic Problems of Synchronization
Monitors
Synchronization Examples
Atomic Transactions
Operating System Concepts – 7th Edition, Feb 8, 2005 6.2 Silberschatz, Galvin and Gagne ©2005
Background
Operating System Concepts – 7th Edition, Feb 8, 2005 6.3 Silberschatz, Galvin and Gagne ©2005
Producer
while (true) {
Operating System Concepts – 7th Edition, Feb 8, 2005 6.4 Silberschatz, Galvin and Gagne ©2005
Consumer
while (true) {
while (count == 0)
; // do nothing
nextConsumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
count--;
Operating System Concepts – 7th Edition, Feb 8, 2005 6.5 Silberschatz, Galvin and Gagne ©2005
Will it work?
Operating System Concepts – 7th Edition, Feb 8, 2005 6.6 Silberschatz, Galvin and Gagne ©2005
Race Condition
register1 = count
register1 = register1 + 1
count = register1
And count-- could be implemented as
register2 = count
register2 = register2 - 1
count = register2
Operating System Concepts – 7th Edition, Feb 8, 2005 6.7 Silberschatz, Galvin and Gagne ©2005
Race Condition (cont.)
Consider this execution interleaving with “count = 5” initially:
T0: producer register1 = count {register1 = 5}
T1: producer register1 = register1 + 1 {register1 = 6}
T2: consumer register2 = count {register2 = 5}
T3: consumer register2 = register2 - 1 {register2 = 4}
T4: producer count = register1 {count = 6 }
T5: consumer count = register2 {count = 4}
The variable “count” could end up with a value of 4, 5, or 6,
depending upon how the execution of the instruction streams is
interleaved (order in which the access to the shared data takes
place). This is called a race condition.
The producer and consumer processes must be synchronized so
that they do not try to execute “count++” and “count--” at the
same time.
Things to remember
Threads interleave executions arbitrarily and at different rates
Scheduling is not under program control
Operating System Concepts – 7th Edition, Feb 8, 2005 6.8 Silberschatz, Galvin and Gagne ©2005
Another Classic Example
Operating System Concepts – 7th Edition, Feb 8, 2005 6.9 Silberschatz, Galvin and Gagne ©2005
Example Continued
Operating System Concepts – 7th Edition, Feb 8, 2005 6.10 Silberschatz, Galvin and Gagne ©2005
Interleaved Schedules
Operating System Concepts – 7th Edition, Feb 8, 2005 6.11 Silberschatz, Galvin and Gagne ©2005
Shared Resources
Operating System Concepts – 7th Edition, Feb 8, 2005 6.12 Silberschatz, Galvin and Gagne ©2005
When Are Resources Shared?
Operating System Concepts – 7th Edition, Feb 8, 2005 6.13 Silberschatz, Galvin and Gagne ©2005
Mutual Exclusion
Operating System Concepts – 7th Edition, Feb 8, 2005 6.14 Silberschatz, Galvin and Gagne ©2005
The Critical-Section Problem
Operating System Concepts – 7th Edition, Feb 8, 2005 6.15 Silberschatz, Galvin and Gagne ©2005
Critical-Section Problem (cont.)
Operating System Concepts – 7th Edition, Feb 8, 2005 6.16 Silberschatz, Galvin and Gagne ©2005
Critical Section Requirements
Operating System Concepts – 7th Edition, Feb 8, 2005 6.17 Silberschatz, Galvin and Gagne ©2005
Solution to Critical-Section Problem (cont.)
3. Bounded Waiting (no starvation) - No process should have to wait
forever. No starvation. i.e. a process attempting to enter its critical
section will be able to do so eventually
Performance: The overhead of entering and exiting the critical section
is small with respect to the work being done within it
NOTE: Race conditions can happen even in kernel code (a data
structure that maintains the list of open files needs to be synch so that
two processes updating the no of open files need to do so correctly)
Two general approaches to handle critical sections in OS kernels:
Nonpreemptive kernels: does not allow preemption. A process will
run until it exits, blocks, or voluntarily releases CPU. This approach
is free from race conditions (Windows XP, 2000)
Preemptive kernels: allows a process to be preempted while
running in kernel mode. Why being used if it leads to race
conditions?
More favorable since its more responsive, more suitable for
real-time programming (Solaris)
Operating System Concepts – 7th Edition, Feb 8, 2005 6.18 Silberschatz, Galvin and Gagne ©2005
Mechanisms For Building Critical Sections
Atomic read/write
Can it be done? depends on the HW
Locks
Primitive, minimal semantics, used to build others
Semaphores
Basic, easy to get the hang of, but hard to program with
Monitors
High-level, requires language support, operations implicit
Messages
Simple model of communication and synchronization based on
atomic transfer of data across a channel
Direct application to distributed systems
Messages for synchronization are straightforward (once we see
how the others work)
Operating System Concepts – 7th Edition, Feb 8, 2005 6.19 Silberschatz, Galvin and Gagne ©2005
Mutual Exclusion with Atomic Read/Writes:
First Try
Operating System Concepts – 7th Edition, Feb 8, 2005 6.20 Silberschatz, Galvin and Gagne ©2005
Peterson’s Solution (Atomic
( R/W)
Operating System Concepts – 7th Edition, Feb 8, 2005 6.21 Silberschatz, Galvin and Gagne ©2005
Processes’ Structure
Process i Process j
Operating System Concepts – 7th Edition, Feb 8, 2005 6.23 Silberschatz, Galvin and Gagne ©2005
Locks
Operating System Concepts – 7th Edition, Feb 8, 2005 6.24 Silberschatz, Galvin and Gagne ©2005
Using Locks
Operating System Concepts – 7th Edition, Feb 8, 2005 6.25 Silberschatz, Galvin and Gagne ©2005
Implementing Locks (1)
This is called a spinlock because a thread spins waiting for the lock
to be released
Does this work?
Operating System Concepts – 7th Edition, Feb 8, 2005 6.26 Silberschatz, Galvin and Gagne ©2005
Implementing Locks (2)
No. Two independent threads may both notice that a lock has been
released and thereby acquire it.
Operating System Concepts – 7th Edition, Feb 8, 2005 6.27 Silberschatz, Galvin and Gagne ©2005
Implementing Locks (3)
Operating System Concepts – 7th Edition, Feb 8, 2005 6.28 Silberschatz, Galvin and Gagne ©2005
Synchronization Hardware
Many OS functions are made simpler and more efficient by support in
hardware.
Many systems provide hardware support for critical section code
(hardware instructions)
Uniprocessors – could disable interrupts while a shared variable is
being modified to solve the critical section problem
Used in nonpreemptive kernels
Currently running code would execute without preemption
Generally too inefficient on multiprocessor systems as disabling
interrupts can be time consuming. (Why?)
Operating systems using this not broadly scalable
Modern machines provide special atomic hardware instructions
Atomic = non-interruptable
Either test memory word and modify its value
Or swap contents of two memory words
Operating System Concepts – 7th Edition, Feb 8, 2005 6.29 Silberschatz, Galvin and Gagne ©2005
TestAndndSet Instruction
Operating System Concepts – 7th Edition, Feb 8, 2005 6.30 Silberschatz, Galvin and Gagne ©2005
Solution using TestAndSet
Mutual exclusion for critical
sections can be achieved via
Process Pi structure:
TestAndSet() by using a boolean while (true) {
lock variable, initialized to
FALSE. acquire();
// critical section
release();
// remainder section
}
Operating System Concepts – 7th Edition, Feb 8, 2005 6.31 Silberschatz, Galvin and Gagne ©2005
Swap Instruction
Operating System Concepts – 7th Edition, Feb 8, 2005 6.32 Silberschatz, Galvin and Gagne ©2005
Solution using Swap
Mutual exclusion for critical sections can be achieved via Swap() by
using a global boolean lock variable, initialized to FALSE, and local
boolean key variables for each process:
Process Pi structure:
while (true) {
key = TRUE;
while ( key == TRUE)
Swap (&lock, &key );
// critical section
lock = FALSE;
// remainder section
Operating System Concepts – 7th Edition, Feb 8, 2005 6.33 Silberschatz, Galvin and Gagne ©2005
Problems with Spinlocks
Operating System Concepts – 7th Edition, Feb 8, 2005 6.34 Silberschatz, Galvin and Gagne ©2005
Disabling Interrupts
Operating System Concepts – 7th Edition, Feb 8, 2005 6.35 Silberschatz, Galvin and Gagne ©2005
On Disabling Interrupts
Operating System Concepts – 7th Edition, Feb 8, 2005 6.36 Silberschatz, Galvin and Gagne ©2005
Summarize Where We Are
Goal: Use mutual exclusion to protect critical sections of code that access
shared resources
Method: Use locks (spinlocks or disable interrupts)
Problem: Critical sections can be long
Operating System Concepts – 7th Edition, Feb 8, 2005 6.37 Silberschatz, Galvin and Gagne ©2005
Higher-Level Synchronization
Spinlocks and disabling interrupts are useful only for very short and simple
critical sections
Wasteful otherwise
These primitives are “primitive” – don’t do anything besides mutual
exclusion
Need higher-level synchronization primitives that:
Block waiters
Leave interrupts enabled within the critical section
All synchronization requires atomicity
Look at two common high-level mechanisms
Semaphores: binary (mutex) and counting
Monitors: mutexes and condition variables
Use them to solve common synchronization problems
So we’ll use our “atomic” locks as primitives to implement them
Operating System Concepts – 7th Edition, Feb 8, 2005 6.38 Silberschatz, Galvin and Gagne ©2005
Implementing Locks (4)
Operating System Concepts – 7th Edition, Feb 8, 2005 6.39 Silberschatz, Galvin and Gagne ©2005
Semaphore
Semaphores are an abstract data type that provides mutual
exclusion ((synchronization) to critical sections
Block waiters, interrupts enabled within CS
Described by Dijkstra in THE system in 1968
Semaphores can also be used as atomic counters
More later
Semaphores are integers that support two operations:
wait(semaphore): decrement, block until semaphore is open
Also P(), after the Dutch word for test, or down()
signal(semaphore): increment, allow another thread to enter
Also V() after the Dutch word for increment, or up()
That's it! No other operations - not even just reading its value -
exist.
Semaphore safety property: a semaphore's value is always greater
than or equal to 0.
Operating System Concepts – 7th Edition, Feb 8, 2005 6.40 Silberschatz, Galvin and Gagne ©2005
Semaphores (cont.)
Thus, a semaphore S is an integer variable that can only be accessed
through two standard atomic operations, wait() and signal():
wait (S) {
while S <= 0
; // no-op
S--;
}
signal (S) {
S++;
}
The modifications to the value of the semaphore (S++ and S--) must be
executed indivisibly. In addition, in wait(), the testing of the integer value of
S (S<=0) and its possible modification (S- -) must be executed without
interruption. (Can be accomplished with TestAndSet() or Swap()
instructions).
The wait() and signal() operations were originally called P() and V(), from
the Dutch words proberen, meaning “to test”, and verhogen, meaning “to
increment”.
Operating System Concepts – 7th Edition, Feb 8, 2005 6.41 Silberschatz, Galvin and Gagne ©2005
Blocking in Semaphores
Operating System Concepts – 7th Edition, Feb 8, 2005 6.42 Silberschatz, Galvin and Gagne ©2005
Semaphore Usage
Two types of semaphores:
Binary semaphore – integer value can range only between 0
and 1; can be simpler to implement
Also known as mutex locks (semaphore)
Represents single access to a resource
Guarantees mutual exclusion to a critical section
Counting (general) semaphore – integer value can range over an unrestricted
domain
Represents a resource with many units available, or a resource that allows
certain kinds of unsynchronized concurrent access (e.g., reading)
Multiple threads can pass the semaphore
Number of threads determined by the semaphore “count”
– mutex has count = 1, counting has count = N
Counting semaphores can be implemented using binary semaphores.
A binary semaphore can be used for critical section mutual exclusion between n
processes
Semaphore S; // initialized to 1
wait (S);
Critical Section
signal (S);
remainder section
Operating System Concepts – 7th Edition, Feb 8, 2005 6.43 Silberschatz, Galvin and Gagne ©2005
Semaphore Usage (cont.)
Operating System Concepts – 7th Edition, Feb 8, 2005 6.44 Silberschatz, Galvin and Gagne ©2005
Semaphore Implementation
Operating System Concepts – 7th Edition, Feb 8, 2005 6.45 Silberschatz, Galvin and Gagne ©2005
Semaphore Implementation (cont.)
Operating System Concepts – 7th Edition, Feb 8, 2005 6.46 Silberschatz, Galvin and Gagne ©2005
Semaphore Implementation (no Busy waiting)
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 – 7th Edition, Feb 8, 2005 6.47 Silberschatz, Galvin and Gagne ©2005
Using Semaphores
Operating System Concepts – 7th Edition, Feb 8, 2005 6.48 Silberschatz, Galvin and Gagne ©2005
Semaphore Implementation (cont.)
The semaphore value can now be negative. If so, its absolute value
is the number of processes waiting on the semaphore.
Bounded waiting can be ensured if the waiting queue is FIFO.
Must guarantee that no two processes can execute wait () and
signal () on the same semaphore at the same time
The wait() and signal() operations must be atomic. (A critical
section problem within the OS—disable interrupts, spin locks.)
Busy waiting not completely eliminated.
Moved from application programs to the kernel.
Spin locks in the kernel can serialize the critical sections of the
wait() and signal() operations, but those sections are short.
Operating System Concepts – 7th Edition, Feb 8, 2005 6.49 Silberschatz, Galvin and Gagne ©2005
Deadlock and Starvation
Operating System Concepts – 7th Edition, Feb 8, 2005 6.50 Silberschatz, Galvin and Gagne ©2005
Classical Problems of Synchronization
Bounded-Buffer Problem
Readers and Writers Problem
Dining-Philosophers Problem
Operating System Concepts – 7th Edition, Feb 8, 2005 6.51 Silberschatz, Galvin and Gagne ©2005
Bounded-Buffer Problem
Operating System Concepts – 7th Edition, Feb 8, 2005 6.52 Silberschatz, Galvin and Gagne ©2005
Bounded Buffer Problem (Cont.)
while (true) {
// produce an item
wait (empty);
wait (mutex);
signal (mutex);
signal (full);
}
Operating System Concepts – 7th Edition, Feb 8, 2005 6.53 Silberschatz, Galvin and Gagne ©2005
Bounded Buffer Problem (Cont.)
while (true) {
wait (full);
wait (mutex);
signal (mutex);
signal (empty);
Operating System Concepts – 7th Edition, Feb 8, 2005 6.54 Silberschatz, Galvin and Gagne ©2005
Readers-Writers Problem
Operating System Concepts – 7th Edition, Feb 8, 2005 6.55 Silberschatz, Galvin and Gagne ©2005
Readers-Writers Problem (Cont.)
Operating System Concepts – 7th Edition, Feb 8, 2005 6.56 Silberschatz, Galvin and Gagne ©2005
Readers-Writers Problem (Cont.)
while (true) {
wait (wrt) ;
// writing is performed
signal (wrt) ;
}
Operating System Concepts – 7th Edition, Feb 8, 2005 6.57 Silberschatz, Galvin and Gagne ©2005
Readers-Writers Problem (Cont.)
The structure of a reader process
while (true) {
wait (mutex) ;
readcount ++ ;
if (readcount == 1) wait (wrt) ;
signal (mutex)
// reading is performed
wait (mutex) ;
readcount - - ;
if (readcount == 0) signal (wrt) ;
signal (mutex) ;
}
Operating System Concepts – 7th Edition, Feb 8, 2005 6.58 Silberschatz, Galvin and Gagne ©2005
Dining-Philosophers Problem
Operating System Concepts – 7th Edition, Feb 8, 2005 6.59 Silberschatz, Galvin and Gagne ©2005
Dining-Philosophers Problem (Cont.)
While (true) {
wait ( chopstick[i] );
wait ( chopStick[ (i + 1) % 5] );
// eat
signal ( chopstick[i] );
signal (chopstick[ (i + 1) % 5] );
// think
Operating System Concepts – 7th Edition, Feb 8, 2005 6.60 Silberschatz, Galvin and Gagne ©2005
Dining-Philosophers Problem (Cont.)
Operating System Concepts – 7th Edition, Feb 8, 2005 6.61 Silberschatz, Galvin and Gagne ©2005
Problems with Semaphores
wait(mutex); (deadlock)
...critical section...
wait(mutex);
Operating System Concepts – 7th Edition, Feb 8, 2005 6.62 Silberschatz, Galvin and Gagne ©2005
Monitors
Operating System Concepts – 7th Edition, Feb 8, 2005 6.63 Silberschatz, Galvin and Gagne ©2005
Structure of a Monitor
monitor monitor-name
{
// shared variable declarations
procedure P1 (…) { …. }
.
.
.
procedure Pn (…) {……}
Operating System Concepts – 7th Edition, Feb 8, 2005 6.64 Silberschatz, Galvin and Gagne ©2005
Schematic view of a Monitor
Operating System Concepts – 7th Edition, Feb 8, 2005 6.65 Silberschatz, Galvin and Gagne ©2005
Condition Variables
Operating System Concepts – 7th Edition, Feb 8, 2005 6.66 Silberschatz, Galvin and Gagne ©2005
Monitor with Condition Variables
Operating System Concepts – 7th Edition, Feb 8, 2005 6.67 Silberschatz, Galvin and Gagne ©2005
Solution to Dining Philosophers
monitor DP
{
enum { THINKING; HUNGRY, EATING) state [5] ;
condition self [5];
Operating System Concepts – 7th Edition, Feb 8, 2005 6.68 Silberschatz, Galvin and Gagne ©2005
Solution to Dining Philosophers (cont)
initialization_code() {
for (int i = 0; i < 5; i++)
state[i] = THINKING;
}
}
Operating System Concepts – 7th Edition, Feb 8, 2005 6.69 Silberschatz, Galvin and Gagne ©2005
Solution to Dining Philosophers (cont)
dp.pickup (i)
EAT
dp.putdown (i)
Operating System Concepts – 7th Edition, Feb 8, 2005 6.70 Silberschatz, Galvin and Gagne ©2005
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 – 7th Edition, Feb 8, 2005 6.71 Silberschatz, Galvin and Gagne ©2005
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 – 7th Edition, Feb 8, 2005 6.72 Silberschatz, Galvin and Gagne ©2005
Monitor Implementation
if (x-count > 0) {
next-count++;
signal(x-sem);
wait(next);
next-count--;
}
Operating System Concepts – 7th Edition, Feb 8, 2005 6.73 Silberschatz, Galvin and Gagne ©2005
Synchronization Examples
Solaris
Windows XP
Linux
Pthreads
Operating System Concepts – 7th Edition, Feb 8, 2005 6.74 Silberschatz, Galvin and Gagne ©2005
Solaris Synchronization
Operating System Concepts – 7th Edition, Feb 8, 2005 6.75 Silberschatz, Galvin and Gagne ©2005
Windows XP Synchronization
Operating System Concepts – 7th Edition, Feb 8, 2005 6.76 Silberschatz, Galvin and Gagne ©2005
Linux Synchronization
Linux:
disables interrupts to implement short critical sections
Linux provides:
semaphores
spin locks
Operating System Concepts – 7th Edition, Feb 8, 2005 6.77 Silberschatz, Galvin and Gagne ©2005
Pthreads Synchronization
Operating System Concepts – 7th Edition, Feb 8, 2005 6.78 Silberschatz, Galvin and Gagne ©2005
Atomic Transactions
System Model
Log-based Recovery
Checkpoints
Concurrent Atomic Transactions
Operating System Concepts – 7th Edition, Feb 8, 2005 6.79 Silberschatz, Galvin and Gagne ©2005
System Model
Operating System Concepts – 7th Edition, Feb 8, 2005 6.80 Silberschatz, Galvin and Gagne ©2005
Types of Storage Media
Operating System Concepts – 7th Edition, Feb 8, 2005 6.81 Silberschatz, Galvin and Gagne ©2005
Log-Based Recovery
Operating System Concepts – 7th Edition, Feb 8, 2005 6.82 Silberschatz, Galvin and Gagne ©2005
Log-Based Recovery Algorithm
Using the log, system can handle any volatile memory errors
Undo(Ti) restores value of all data updated by Ti
Redo(Ti) sets values of all data in transaction Ti 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 – 7th Edition, Feb 8, 2005 6.83 Silberschatz, Galvin and Gagne ©2005
Checkpoints
Operating System Concepts – 7th Edition, Feb 8, 2005 6.84 Silberschatz, Galvin and Gagne ©2005
Concurrent Transactions
Operating System Concepts – 7th Edition, Feb 8, 2005 6.85 Silberschatz, Galvin and Gagne ©2005
Serializability
Operating System Concepts – 7th Edition, Feb 8, 2005 6.86 Silberschatz, Galvin and Gagne ©2005
Schedule 1: T0 then T1
Operating System Concepts – 7th Edition, Feb 8, 2005 6.87 Silberschatz, Galvin and Gagne ©2005
Nonserial Schedule
Operating System Concepts – 7th Edition, Feb 8, 2005 6.88 Silberschatz, Galvin and Gagne ©2005
Schedule 2: Concurrent Serializable Schedule
Operating System Concepts – 7th Edition, Feb 8, 2005 6.89 Silberschatz, Galvin and Gagne ©2005
Locking Protocol
Operating System Concepts – 7th Edition, Feb 8, 2005 6.90 Silberschatz, Galvin and Gagne ©2005
Two-phase Locking Protocol
Operating System Concepts – 7th Edition, Feb 8, 2005 6.91 Silberschatz, Galvin and Gagne ©2005
Timestamp-based Protocols
Operating System Concepts – 7th Edition, Feb 8, 2005 6.92 Silberschatz, Galvin and Gagne ©2005
Timestamp-based Protocol Implementation
Operating System Concepts – 7th Edition, Feb 8, 2005 6.93 Silberschatz, Galvin and Gagne ©2005
Timestamp-ordering Protocol
Operating System Concepts – 7th Edition, Feb 8, 2005 6.94 Silberschatz, Galvin and Gagne ©2005
Schedule Possible Under Timestamp Protocol
Operating System Concepts – 7th Edition, Feb 8, 2005 6.95 Silberschatz, Galvin and Gagne ©2005
End of Chapter 6