Operating Systems
Certificate Program in Software Development
CSE-TC and CSIM, AIT
September -- November, 2003
5. Process Synchronization
(Ch. 6, S&G)
ch 7 in the 6th ed.
 Objectives
– describe the synchronization problem and
some common mechanisms for solving it
OSes: 5. Synch
1
Contents
1. Motivation: Bounded Buffer
2. Critical Sections
3. Synchronization Hardware
4. Semaphores
5. Synchronization Examples
OSes: 5. Synch
continued
2
6.
Problems with Semaphores
7.
Critical Regions
8.
Monitors
9.
Synchronization in Solaris 2
10. Atomic Transactions
OSes: 5. Synch
3
1. Motivation: Bounded Buffer
bounded buffer
…..
0
producer
OSes: 5. Synch
1 2 3
write
…..
n-1
read
consumer
4
Producer Code (pseudo-Pascal)
:
repeat
. . .
/* produce an itemP */
. . .
while (counter == n) do
no-op;
buffer[in] := itemP;
in := (in+1) mod n;
counter := counter + 1;
until false;
:
OSes: 5. Synch
/* write */
5
Consumer Code
:
repeat
while (counter == 0) do
no-op;
itemC := buffer[out];
/* read */
out := (out+1) mod n;
counter := counter - 1;
. . .
/* use itemC for something */
. . .
until false;
:
OSes: 5. Synch
6
Problem
 Assume counter == 5
 producer run
:
counter :=
counter + 1;
:

counter
OSes: 5. Synch
consumer run
:
counter :=
counter - 1;
:
may now be 4, 5, or 6. Why?
7
Machine Language

“counter := counter + 1”
reg1 := counter
reg1 := reg1 + 1
counter := reg1
becomes:
 “counter := counter - 1”
reg2 := counter
reg2 := reg2 - 1
counter := reg2
OSes: 5. Synch
becomes:
8
Execution Interleaving
 The
concurrent execution of the two
processes is achieved by interleaving the
execution of each
 There
are many possible interleavings,
which can lead to different values for
counter
– a different interleaving may occur each time
the processes are run
OSes: 5. Synch
9
Interleaving Example
 Initially: counter == 5
 Execution:
reg1 :=
reg1 :=
reg2 :=
reg2 :=
counter
counter
OSes: 5. Synch
counter
reg1 + 1
counter
reg2 - 1
:= reg1
:= reg2
//
//
//
//
//
//
reg1 ==
reg1 ==
reg2 ==
reg2 ==
counter
counter
5
6
5
4
== 6
== 4
10
Summary of Problem
 Incorrect
results occur because of a race
condition over the modification of the
shared variable (counter)
 The
processes must be synchronized while
they are sharing data so that the result is
predictable and correct
OSes: 5. Synch
11
2. Critical Sections
 A critical
section is a segment of code
which can only be executed by one process
at a time
– all other processes are excluded
– called mutual exclusion
OSes: 5. Synch
12
Critical Section Pseudo-code
repeat
entry section
critical section
exit section
remainder section
until false;
OSes: 5. Synch
13
Implementation Features
 An
implementation of the critical section
idea must have three features:
– mutual exclusion
– progress
 the
next process to enter the critical region is
decided solely by looking at those waiting in their
entry sections
– bounded waiting
 no
OSes: 5. Synch
process should wait forever in their entry section
14
2.1. Solutions for Two Processes
 Algorithm
1 (take turns)
– shared data:
var turn: 0..1 := 0;
/* or 1 */
– Code for process i:
repeat
while (turn /== i) do no-op:
critical section;
turn := j;
progress requirement
remainder section;
not met
until false;
OSes: 5. Synch
15
Algorithm2
(who wants to enter?)
 Shared data:
var flag : array [0..1] of boolean
:= {false, false};
 Code for process i:
repeat
flag[i] := true;
while (flag[j]) do no-op:
critical section;
flag[i] := false;
remainder section;
progress requirement
until false;
still not met
OSes: 5. Synch
16
Algorithm 3
 Combines
(Peterson, 1981)
algorithms 1 and 2
– who wants to enter?
– if both do then take turns
 Shared data:
var flag : array [0..1] of boolean
:= {false, false};
var turn : 0..1 := 0;
OSes: 5. Synch
/* or 1 */
continued
17
 Code for process i:
repeat
flag[i] := true;
turn := j;
while (flag[j] and turn == j) do
no-op:
critical section;
flag[i] := false;
remainder section;
until false;
OSes: 5. Synch
18
2.2. Multiple Processes
 Uses
the bakery algorithm (Lamport 1974).
 Each
customer (process) receives a number
on entering the store (the entry section).
 The
customer with the lowest number is
served first (enters the critical region).
OSes: 5. Synch
continued
19
 If
two customers have the same number,
then the one with the lowest name is served
first
– names are unique and ordered
OSes: 5. Synch
20
Pseudo-code
 Shared data:
var choosing : array [0..n-1]
of boolean
:= {false .. false};
var number : array [0..n-1]
of integer
:= {0 .. 0};
OSes: 5. Synch
continued
21
 Code
for process i:
repeat
choosing[i] := true;
number[i] := max(number[0], number[1],
. . ., number[n-1]) + 1;
choosing[i] := false;
for j := 0 to n-1 do
begin
while (choosing[j]) do no-op;
while ((number[j] /== 0) and
((number[j],j) < (number[i],i))) do no-op;
end;
critical section
number[i] := 0;
remainder section
until false;
OSes: 5. Synch
22
3. Synchronization Hardware
 Hardware
solutions can make software
synchronization much simpler
 On
a uniprocessor, the OS can disallow
interrupts while a shared variable is being
changed
– not so easy on multiprocessors
OSes: 5. Synch
continued
23
 Typical
hardware support:
– atomic test-and-set of a boolean (byte)
– atomic swap of booleans (bytes)
 Atomic
means an uninterruptable ‘unit’ of
work.
OSes: 5. Synch
24
3.1. Atomic Test-and-Set
function Test-and-Set(
var target : boolean) : boolean
begin
Test-and-Set := target;
target := true;
end;
OSes: 5. Synch
25
Use
lock/in lock/out result action
F
T
F
proceed
T
T
T
loop
 Shared data:
var lock : boolean := false;
 Process code for mutual exclusion:
repeat
while (Test-and-Set(lock) do
no-op;
critical section
lock := false;
remainder section
until false;
OSes: 5. Synch
26
3.2. Atomic Swap
procedure Swap(var a, b : boolean)
var temp : boolean;
begin
temp := a;
a := b;
b := temp;
end;
OSes: 5. Synch
27
Use
key1
in: T
key2
T
…
…
keyN lock
T
F
 Shared data:
var lock : boolean := false;
 Process code for m.e.:
var key : boolean:
repeat
key := true;
repeat
Swap(lock, key);
until (key == false);
critical section
lock := false;
remainder section
until false;
OSes: 5. Synch
28
3.3. Bounded Waiting
 TestAndSet()
and Swap() both satisfy the
requirements of mutual exclusion and
progress
 But
bounded waiting is not satisfied
 We
must add an extra data structure to code
FIFO (queueing-style) behaviour
OSes: 5. Synch
29
4. Semaphores
(Dijkstra, 1965)
 Semaphores
are a synchronization tool
based around two atomic operations:
OSes: 5. Synch
– wait()
sometimes called P()
– signal()
sometimes called V()
30
4.1. Definitions
same as integer
procedure wait(var S : semaphore)
begin
while (S =< 0) do
no-op;
S := S - 1;
end;
procedure signal(var S : semaphore)
begin
S := S + 1;
end;
OSes: 5. Synch
31
4.2. Mutual Exclusion with Semaphores
 Shared data:
var mutex : semaphore := 1;
 Process code:
repeat
wait(mutex);
critical section;
signal(mutex);
remainder section;
until false;
OSes: 5. Synch
32
4.3. Ordering Processes
 Establish
a fixed order for two processes
p1 and p2 , We set semaphore Order := 0.
 If
the desired order is p1 -> p2, p2 should
issue a wait(Order), and then wait until p1
issues a signal(Order).
OSes: 5. Synch
33
4.4. Counting Semaphores
 Allow
N processes into a critical section,
by initialising semaphore Limit to N
– the first N processes each decrement Limit
using wait(Limit), until Limit == 0, at
which time new processes must wait
 This
approach is used for controlling
access to a limited number of resources
(e.g. N resources)
OSes: 5. Synch
34
4.5. Implementations
 Our wait()
implementation uses busy-waiting
– sometimes called a spinlock
 An
alternative is for the process calling wait()
to block
– place itself on a wait list associated with the
semaphore
– signal() chooses a blocked process to become
ready
OSes: 5. Synch
35
New Semaphore Data Type
type semaphore =
record
value : integer;
L : list of waiting-processes;
end;
OSes: 5. Synch
36
New Operations
procedure wait(var S : semaphore)
begin
S.value := S.value - 1;
if (S.value < 0) then
begin
/* add the calling process to S.L */
. . .
block;
end;
end;
OSes: 5. Synch
continued
37
procedure signal(var S : semaphore)
begin
S.value := S.value + 1;
if (S.value =< 0) then
begin
/* remove a process P from S.L */
. . .
wakeup(P);
end;
end;
OSes: 5. Synch
38
4.6. Deadlocks & Starvation
 Deadlock
occurs when every process is
waiting for a signal(S) call that can only be
carried out by one of the waiting processes.
 Starvation
occurs when a waiting process
never gets selected to move into the critical
region.
OSes: 5. Synch
39
4.7. Binary Semaphores
 A binary
semaphore is a specialisation of
the counting semaphore with S only having
a range of 0..1
– S starts at 0
– easy to implement
– can be used to code up counting semaphores
OSes: 5. Synch
40
5. Synchronization Examples
OSes: 5. Synch
 5.1.
Bounded Buffer
 5.2.
Readers and Writers
 5.3.
Dining Philosophers
41
5.1. Bounded Buffer (Again)
bounded buffer
…..
0
producer
OSes: 5. Synch
1 2 3
write
…..
n-1
read
consumer
42
Implementation
 Shared data:
var buffer : array[0..n-1] of Item;
var mutex : semaphore := 1;
/* for access to buffer */
var full : semaphore := 0;
/* num. of used array cells */
var empty : semaphore := n;
/* num. of empty array cells */
OSes: 5. Synch
43
Producer Code
repeat
. . .
/* produce an itemP */
. . .
wait(empty);
wait(mutex);
buffer[in] := itemP;
in := (in+1) mod n;
signal(mutex);
signal(full);
until false;
OSes: 5. Synch
44
Consumer Code
repeat
wait(full);
wait(mutex);
itemC := buffer[out];
out := (out+1) mod n;
signal(mutex);
signal(empty);
. . .
/* use itemC for something */
. . .
until false;
OSes: 5. Synch
45
5.2. Readers & Writers
 Readers
make no change to the shared data
(e.g. a file)
– no synchronization problem
 Writers
do change the shared data
 Multiple
writers (or a writer and readers)
cause a synchronization problem.
OSes: 5. Synch
46
Many Variations
 1.
Don’t keep a reader waiting unless a
writer is already using the shared data
– writers may starve
 2.
Don’t keep a writer waiting
– readers may starve
OSes: 5. Synch
47
Variation 1
 Shared data:
var shared-data : Item;
var readcount : integer : = 0;
/* no. of readers currently
using shared-data */
var mutex : semaphore := 1;
/* control access to readcount */
var wrt : semaphore := 1;
/* used for m.e. of writers */
OSes: 5. Synch
48
Writer’s Code
:
wait(wrt);
. . .
/* writing is performed */
. . .
signal(wrt);
:
OSes: 5. Synch
49
Reader’s Code
wait(mutex);
readcount := readcount + 1;
if (readcount == 1) then
wait(wrt);
signal(mutex);
. . .
/* reading is performed */
. . .
wait(mutex);
readcount := readcount - 1;
if (readcount == 0) then
signal(wrt);
signal(mutex);
OSes: 5. Synch
50
5.3. Dining Philosophers
Dijkstra, 1965

OSes: 5. Synch
An example of the
need to allocate several
resources (chopsticks)
among processes
(philosophers) in a
deadlock and
starvation free manner.
51
Implementation
 Represent
each chopstick by a semaphore.
Shared data:
var chopstick : array[0..4]
of semaphore
:= {1,1,1,1,1};
 A chopstick
is ‘picked up’ with:
wait(chopstick[pos])
and ‘set down’ with:
signal(chopstick[pos])
OSes: 5. Synch
52
Code for Philopospher i
repeat
wait( chopstick[i] );
wait( chopstick[(i+1) mod 5] );
/* . . . eat . . . */
signal( chopstick[i] );
signal( chopstick[(i+1) mod 5] );
/* . . . think . . . */
until false;
OSes: 5. Synch
53
Deadlock
 This
solution avoids simultaneous use of
chopsticks (good)
 But
if all the philosophers pick up their left
chopstick together, then they will deadlock
while waiting for access to their right
chopstick.
OSes: 5. Synch
54
Possible Fixes
 Allow
at most 4 philosophers to be at the table
at a time.
 Have
a philosopher pick up their chopsticks
only if both are available (in a critical section)
 Alternate
the order that chopsticks are picked
up depending on whether the philosopher is
seated at an odd or even seat
OSes: 5. Synch
55
6. Problems with Semaphores
 The
reversal of a wait() and signal() pair
will break mutual exclusion
 The
omission of either a wait() or signal()
will potentially cause deadlock
 These
problems are difficult to debug and
reproduce
OSes: 5. Synch
56
Higher level Synchronization
 These
problems have motivated the
introduction of higher level constructs:
– critical regions
– monitors
– condition variables
 These
constructs are safer, and easy to
understand
OSes: 5. Synch
57
7. Critical Regions
 Shared variables are explicitly
var v : shared ItemType;
Hoare, 1972;
Brinch Hansen, 1972
declared:
 A shared
variable can only be accessed within
the code part (S) of a region statement:
region v do S
– while code S is being executed, no other process
can access v
OSes: 5. Synch
58
Conditional Critical Regions

region v when B do S
– only execute S when the boolean expression B
evaluates to true, otherwise wait until B is true
– as before, while code S is being executed, no
other process can access v
OSes: 5. Synch
59
Bounded Buffer Again
 Shared
data:
var buffer : shared record
pool : array[0..n-1] of Item;
count, in, out : integer;
end;
OSes: 5. Synch
60
Producer Code
region buffer when (count < n) do
begin
pool[in] := itemP;
in := (in+1) mod n;
count := count + 1;
end;
OSes: 5. Synch
61
Consumer Code
region buffer when (count > 0) do
begin
itemC := pool[out];
out := (out+1) mod n;
count := count - 1;
end;
OSes: 5. Synch
62
8. Monitors
queues associated
var
with condition
variables
Brinch Hansen, 1973
shared data
entry queue of
waiting processes
operations
Fig. 6.20, p.184
OSes: 5. Synch
initialization
code
63
Monitor Syntax
type monitor-name = monitor
variable declarations
procedure entry p1(. . .)
begin . . . end;
:
begin
initialization code
end.
OSes: 5. Synch
64
Features
 When
an instance of a monitor is created, its
initialization code is executed
 A procedure
can access its own variables
and those in the monitor’s variable
declarations
 A monitor
only allows one process to use its
operations at a time
OSes: 5. Synch
65
An OO View of Monitors
 A monitor
is similar to a class
 An
instance of a monitor is similar to an
object, with all private data
 Plus
synchronization: invoking any
operation (method) results in mutual
exclusion over the entire object
OSes: 5. Synch
66
8.1. Condition Variables
 Notation:
var x : condition;
x.wait;
suspend
calling process
x.signal;
resumes
one of the suspended
processes waiting on x
OSes: 5. Synch
67
Condition Variables in Monitors
 What
happens when signal is issued?
 The
unblocked process will be placed on the
ready queue and resume from the statement
following the wait.
 This
would violate mutual exclusion if both
the signaller and signalled process are
executing in the monitor at once.
OSes: 5. Synch
68
Three Possible Solutions
 1.
Have the signaller leave the monitor
immediately after calling signal
 2.
Have the signalled process wait until the
signaller has left the monitor
 3.
Have the signaller wait until the
signalled process has left the monitor
OSes: 5. Synch
69
8.2. Dining Philosophers (Again)
 Useful
data structures:
var state : array[0..4] of
(thinking, hungry, eating);
var self : array[0..4] of condition;
/* used to delay philosophers */
 The
approach is to only set state[i] to
eating if its two neigbours are not eating
– i.e.
and
OSes: 5. Synch
state[(i+4) mod 5]
state[(i+1) mod 5]
=
=
eating
eating
70
Using the dining-philosophers Monitor
 Shared data:
var dp : dining-philosopher;
 Code
in philosopher i:
dp.pickup(i):
/* . . . eat . . . */
dp.putdown(i);
OSes: 5. Synch
71
Monitor implementation
type dining-philosophers = monitor
var state : array[0..4] of
(thinking, hungry, eating);
var self : array[0..4] of condition;
procedure entry pickup(i : 0..4)
begin
state[i] := hungry;
test(i);
if (state[i] /== eating) then
self[i].wait;
end;
OSes: 5. Synch
continued
72
procedure entry putdown(i : 0..4)
begin
state[i] := thinking;
test((i+4) mod 5);
test((i+1) mod 5);
end;
OSes: 5. Synch
continued
73
procedure test(k : 0..4)
begin
if ((state[(k+4) mod 5] /== eating)
and (state[k] == hungry)
and (state[(k+1) mod 5]
/== eating)) then
begin
state[k] := eating;
self[k].signal;
end;
end;
OSes: 5. Synch
continued
74
begin
/* initialization of monitor instance */
for i := 0 to 4 do
state[i] := thinking;
end.
OSes: 5. Synch
75
8.3. Problems with Monitors
 Even
 For
high level operations can be misused.
correctness, we must check:
– that all user processes always call the monitor
operations in the right order;
– that no user process bypasses the monitor and
uses a shared resource directly
– called the access-control problem
OSes: 5. Synch
76
9. Synchronization in Solaris 2
 Uses
a mix of techniques:
– semaphores using spinlocks
– thread blocking
– condition variables (without monitors)
– specialised reader-writer locks on data
OSes: 5. Synch
77
10. Atomic Transactions
 We
want to do all the operations of a critical
section as a single logical ‘unit’ of work
– it is either done completely or not at all
 A transaction
can be viewed as a sequence
of reads and writes on shared data, ending
with a commit or abort operation
 An abort
causes a partial transaction to be
rolled back
OSes: 5. Synch
78
10.1. Log-based Recovery
 Atomicity
is ensured by logging transaction
operations to stable storage
– these can be replayed or used for rollback if
failure occurs
 Log
details:
– transaction name, data name, old value,
new value
OSes: 5. Synch
continued
79
 Write-ahead
logging:
– log a write operation before doing it
– log the transaction start and its commit
OSes: 5. Synch
80
Example
begin transaction
read X
if (X >= a) then
{
read Y
X = X - a
Y = Y + a
write X
write Y
}
end transaction
OSes: 5. Synch
(VUW CS 305)
<Ti, start>
<Ti, X, oldV, newV>
<Ti, Y, oldV, newV>
<Ti, commit>
81
Recovery
 Operations:
– undo( Transactioni )
– redo( Transactioni )
 Possible
states of Transactioni
– committed, but were new values written?
– aborted, but were old values restored?
– unfinished
OSes: 5. Synch
82
10.2. Checkpoints
 A checkpoint
fixes state changes by writing
them to stable storage so that the log file
can be reset or shortened.
OSes: 5. Synch
83
10.3. Concurrent Atomic Transactions
 We
want to ensure that the outcome of
concurrent transactions are the same as if
they were executed in some serial order
– serializability
OSes: 5. Synch
84
A Serial Schedule
 Transaction
0
Fig. 6.23, p.195
Transaction 1
read A
write A
read B
write B
read A
write A
read B
write B
OSes: 5. Synch
85
Conflicting Operations
 Two
operations in different transactions
conflict if they access the same data and one
of them is a write.
 Serializability
must avoid conflicting
operations:
– it can do that by delaying/speeding up when
operations in a transaction are performed
OSes: 5. Synch
86
A Concurrent Serializable Schedule
Fig. 6.24, p.196
 Transaction
0
Transaction 1
read A
write A
read A
write A
read B
write B
read B
write B
OSes: 5. Synch
87
10.4. Locks
 Serializability
can be achieved by locking
data items
 There
are a range of locking modes:
– a shared lock allows multiple reads by
different transactions
– an exclusive lock allows only one transaction
to do reads/writes
OSes: 5. Synch
88
10.5. Timestamping
 One
way of ordering transactions
 Using
the system clock is not sufficient
when transactions may originate on
different machines
OSes: 5. Synch
89