Operating Systems (CS-205)

Lecture 16-17
Operating System – Synchronization

Tayyeb Javed
Lecturer
Department of Computer Science
tayyeb.javed@nu.edu.pk
 CPU Scheduling
Objectives
The Critical-Section Problem
Synchronization Hardware
Semaphores
Classical Problems of Synchronization

2 Advanced Operating System- Synchronization 03/04/2016

 Semaphores
 A Semaphore S is an
integer variable that, apart
from initialization, can
only be accessed through
2 atomic and mutually
exclusive operations:
 wait(S)
sometimes called P()
 Dutch proberen: “to test”
 signal(S)
sometimes called V()
 Dutch verhogen:
increment”
 The classical definition of
wait and signal is as shown
in the following figures
 Useful when critical sections
last for a short time, or we
have lots of CPUs
 S initialized to positive value
(to allow someone in at the
beginning)
wait(S) {
while S<=0 do ;
S- -; }
“to signal(S) {
S++; }

3 Advanced Operating System- Synchronization 03/04/2016

 Semaphores in Action

Initialize mutex to 1

Process Pi: Process Pj:

repeat repeat
wait(mutex); wait(mutex);
CS CS
signal(mutex); signal(mutex);
RS RS
forever forever

4 Advanced Operating System- Synchronization 03/04/2016

 Semaphores: the Problem of busy
waiting
 Semaphore definitions (so far) all require busy waiting
 This type of semaphore is called spinlock
 This continual looping is a problem in a multiprogramming
setting
 As a solution, modify the definition of the wait and signal
 Define a semaphore as a
semaphores Semaphore operations now defined as
record wait(S):
typedef struct { S.value - -;
int value; if (S.value < 0) {
struct process *L; add this process to S.L;
} semaphore; block; }

signal(S):
 Assume two simple S.value++;
operations: if (S.value <= 0) {
block suspends the process that remove a process P from S.L;
invokes it. wakeup(P); }
5 Advanced Operating System- Synchronization 03/04/2016
 wakeup( P) resumes the
execution of a blocked process P
 Synchronizing Processes using
Semaphores
 Two processes: Define a semaphore “synch”
P1 and P2 Initialize synch to 0
 Statement S1 in P1 needs to
be performed before Put this in P2:
statement S2 in P2 wait(synch);
 We want a way to make P2 S2;
wait
Until P1 tells it is OK to And this in P1:
proceed S1;
signal(synch);

6 Advanced Operating System- Synchronization 03/04/2016

 Deadlock and Starvation
 An implementation of a semaphore with a waiting queue may
result in:
Deadlock: two or more processes are waiting indefinitely for
an event that can be caused only by 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
7  If weOperating
Advanced add orSystem-
remove processes from the list associated03/04/2016
Synchronization with a
semaphore in LIFO manner
 Classical Problems of
Synchronization
Bounded-buffer problem
Reader-Writer Problem
Dining Philosophers Problem
Monitors

8 CS-205 Operating System 8-Mar-2016

 Classical Problems of Synchronization:
Bounded-Buffer Problem
 Shared data: semaphore full, empty, mutex;
 Initially: full = 0, empty = n, mutex = 1
 We have n buffers. Each buffer is capable of
holding ONE item
do {
do {
wait(full)
…
wait(mutex);
produce an item in
…
nextp
remove an item from
…
buffer to nextc
wait(empty);
…
wait(mutex);
signal(mutex);
…
signal(empty);
add nextp to buffer
…
…
consume the item in nextc
signal(mutex);
…
signal(full);
} while (1);
} while (1);
9 Advanced Operating System- Synchronization 03/04/2016
 Classical Problems of Synchronization:
Readers-Writers Problem
 There is one writer and multiple readers
 The writer wants to write to the database
 The readers wants to read from the database
 We can not allow a writer and a reader writing
and reading the database at the same time
 We can allow one or more readers reading
from the database at the same time
 Two different versions:
 First reader-writers problem
 Second readers-writers problem

10 Advanced Operating System- Synchronization 03/04/2016

 Reader-writers problem (Cont.)

11 CS-205 Operating System 8-Mar-2016

 Reader-writers problem (Cont.)

12 CS-205 Operating System 8-Mar-2016

 Reader-writers problem (Cont.)

13 CS-205 Operating System 8-Mar-2016

 First Solution: Reader’s precedence
Reader() { Writer() {
while(TRUE) { while(TRUE) {
wait(mutex); wait(wrt);
readCount++; write(resource);
if(readCount==1) signal(wrt);
wait(wrt); }
}
signal(mutex);
read(resource); resourceType *resource;
int readCount = 0;
wait(mutex);
semaphore mutex = 1;
readCount--;
semaphore wrt = 1;
if(readCount == 0)
signal(wrt);  First reader competes with
signal(mutex); writers
}}  Last reader signals writers
14 CS-205 Operating System 8-Mar-2016
 First Solution: reader’s precedence
Reader() { Writer() {
while(TRUE) { while(TRUE) {
wait(mutex);
wait(wrt);
readCount++;
if(readCount==1) write(resource);
wait(wrt);
signal(wrt);
signal(mutex); }
}
read(resource);  First reader competes with
wait(mutex); writers
readCount--;  Last reader signals writers
if(readCount == 0)  Any writer must wait for all
signal(wrt); readers
signal(mutex);  Readers can starve writers
}}  “Updates” can be delayed
15 CS-205 Operating System forever 8-Mar-2016
 Second Solution: Writer’s
precedence
Reader() { writer() {
2 while(TRUE) { while(TRUE) {
wait(rd); wait(mutex2);
wait(mutex1); writeCount++;
readCount++; if(writeCount == 1)
if(readCount == 1) 1 wait(rd);
wait(wrt); signal(mutex2);
signal(mutex1); 3 wait(wrt);
signal(rd); write(resource);
read(resource); signal(wrt);
wait(mutex1); wait(mutex2)
readCount--; writeCount--;
if(readCount == 0) if(writeCount == 0)
signal(wrt); 4 signal(rd);
signal(mutex1); signal(mutex2);
} int readCount = 0, writeCount = 0;
} semaphore mutex1 = 1, mutex2 = 1;
semaphore rd = 1, wrt = 1;
16 CS-205 Operating System 8-Mar-2016
 The Dining Philosophers Problem
A classical
synchronization
problem
5 philosophers who only
eat and think
Each need to use 2 forks
for eating
There are only 5 forks
Illustrates the difficulty
of allocating resources
among process without
17 deadlock
CS-205 and starvation
Operating System 8-Mar-2016
 The Dining Philosopher Problem
Each philosopher is a
process
One semaphore per fork:
Fork: array[0..4] of
Pi() {
semaphores
while(TRUE){
Initialization: think;
fork[i].count:=1 for i:=0..4 wait(fork[i]);
wait(fork[i+1 mod 5]);
A first attempt:
eat;
Deadlock if each signal(fork[i+1 mod 5]);
philosopher starts by signal(fork[i]);
}
picking his left fork!
}
18 CS-205 Operating System 8-Mar-2016
 The Dining Philosophers Problem
Idea: admit only 4 Pi(){
while(TRUE){
philosophers at a time think;
who try to eat wait(T);
wait(fork[i]);
Then, one philosopher
wait(fork[i+1 mod 5]);
can always eat when the eat;
other 3 are holding one signal(fork[i+1 mod 5]);
signal(fork[i]);
fork signal(T);
Solution: use another }
semaphore T to limit at }
4 the number of
philosophers “sitting at
19
theOperating
CS-205 table”System 8-Mar-2016

 Recall: Problems with Semaphores
Semaphores are a powerful tool for enforcing
mutual exclusion and coordinate processes
Problem: wait(S) and signal(S) are scattered
among several processes
It is difficult to understand their effects
Usage must be correct in all processes
One bad (or malicious) process can fail the entire
collection of processes

20 CS-205 Operating System 8-Mar-2016

 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 (…) { …. }
…
procedure Pn (…) {……}
Initialization code ( ….) { … }
}
21 CS-205 Operating System 8-Mar-2016
 Monitors
Is a software module containing:
one or more procedures
an initialization sequence
local shared data variables
Characteristics:
Local shared variables accessible only by monitor’s
procedures
a process enters the monitor by invoking one of it’s
procedures
only one process can be in the monitor at any one time
The monitor ensures mutual exclusion
no need to program this constraint explicitly

22
Shared
CS-205 Operatingdata
Systemare protected by placing them in8-Mar-2016
the
monitor
 Condition Variables
Process synchronization is done using condition
variables, which represent conditions a process may
need to wait for before executing in the monitor
condition x, y;
Local to the monitor (accessible only within the
monitor)
Can be accessed and changed only by two
functions:
x.wait(): blocks execution of the calling process on
condition x
 the process can resume execution only if another process executes
x.signal()
23  Operating System
x.signal(): resume execution of some process blocked
CS-205 on
8-Mar-2016
 Monitors
Awaiting processes are
either in the entrance
queue or in a condition
queue
A process puts itself into
condition queue cn by
issuing cn.wait()
cn.signal() brings into
the monitor one process
in condition cn queue
signal-and-wait and
signal-and-continue
24 CS-205 Operating System 8-Mar-2016
 Producer Consumer using Monitor
 Two types of processes: Producer:
 producers
 consumers
while(TRUE){
 Synchronization is now produce item;
confined within the monitor append(item);
 append(.) and take(.) are }
procedures within the Consumer:
monitor: are the only means
while(TRUE){
by which P/C can access the
buffer item=take();
 If these procedures are consume item;
correct, synchronization will }
be correct for all
25 participating
CS-205 processes
Operating System 8-Mar-2016
 Monitor for the Bounded P/C
Problem
Buffer:
buffer: array[0..k-1] of items;
Buffer pointers and counts:
nextin: points to next item to be appended
nextout: points to next item to be taken
count: holds the number of items in the buffer
Condition variables:
notfull: notfull.signal() indicates that the buffer is not
full
notempty: notempty.signal() indicates that the buffer is
not empty
26 CS-205 Operating System 8-Mar-2016
 Monitor for bounded buffer problem
Monitor boundedbuffer { Item Take(){
Item buffer[k]; if (count==0)
integer nextin, nextout, count; notempty.wait();
condition notfull, notempty; v = buffer[nextout];
Append(v){ nextout =
if (count==k) (nextout+1) mod k;
notfull.wait(); count--;
buffer[nextin] = v; notfull.signal();
nextin = (nextin+1) mod k; return v;
count++; }
notempty.signal(); }
}
initialization_code(){
nextin=0; nextout=0; count=0;
}
27 CS-205 Operating System 8-Mar-2016
 Synchronization Primitives —
Summary
SHARED MEMORY NO SHARED MEMORY

monitors message passing

high level critical regions remote procedure calls
sockets

low level semaphores

hardware load/store
interrupt
disable/enable
test-and-set

28 Advanced Operating System- Synchronization 03/04/2016

 Priority Inversion
Lower priority process makes the higher process
wait while it is holding a resource that the higher
priority process needs
L < M < N
Solution1: Use only two priorities
Solution2: Inherit priority

29 CS-205 Operating System 13-Apr-2016

 Transactional Memory
Multi-core systems
A memory transaction
Sequence of memory read-write operations that are
atomic
If all operations are completed, transaction is
committed
Otherwise, rolled back
As the number of threads increase, the use of
traditional locking doesn’t scale well

30 CS-205 Operating System 13-Apr-2016

 When transaction fails
What should the system do…
Recovery
Rollback
Redo

31 CS-205 Operating System 13-Apr-2016

 Log-based Recovery
Write-ahead logging
Transaction name
Data item name
Old value
New value
<Ti starts>
<Ti commits>
Undo(Ti) if log contains <Ti starts> and does not
contains <Ti commits>
Redo(Ti) if log contains <Ti starts> and also contains
32 <T commits>
CS-205 Operating System
i
13-Apr-2016
 Checkpoints
Periodic checkpoints in the log
Output all log to stable storage
Output all modified data residing in volatile storage to
stable storage
Output log <checkpoint> onto stable storage
Recovery
Search log backward
Find first check point and then the subsequent <Ti start>
without any commit
For all transactions Tk in T with commit exists
redo(Tk)
33 CS-205 Operating System 13-Apr-2016
For all transactions Tk without commit execute
 Concurrent atomic transactions
Serializability
T0 T1
read(A)
write(A)
read(B)
write(B)
read(A)
write(A)
read(B)
write(B)

34 CS-205 Operating System 13-Apr-2016

 Concurrent atomic transactions
Serializability (serial schedule)
Conflicting operations
T0 T1
read(A)
write(A)
read(A)
write(A)
read(B)
write(B)
read(B)
write(B)

35 CS-205 Operating System 13-Apr-2016