Operating Systems
CMPSCI 377
Lecture 9: Synchronization III
Emery Berger
University of Massachusetts, Amherst
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
Last Time: Locks & Semaphores


More on hardware support
Implementing locks



Test & Set
Busy waiting
Semaphores

Generalization of locks
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
2
This Time: More Synch Primitives



Reader-Writer Locks
Monitors
Condition Variables
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
3
Reader/Writers Problem

Suppose one object shared among many threads
W

R
W
R
Each thread is either a reader or a writer



R
Readers – only read data, never modify
Writers – read & modify data
How should we control access to this object?

Which synchronization primitive?
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
4
Single Lock
thread A
thread B
thread C
Lock.acquire()
Read data
Lock.release()
Lock.acquire()
Modify data
Lock.release()
Lock.acquire()
Read data
Lock.release()
thread D
thread E
thread F
Lock.acquire()
Read data
Lock.release()
Lock.acquire()
Read data
Lock.release()
Lock.acquire()
Modify data
Lock.release()

Drawbacks of this solution?
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
5
Readers/Writers Optimization

Single lock: safe, but limits concurrency


Only one thread at a time, but…
Safe to have simultaneous readers!


But only one writer at a time
Must guarantee mutual exclusion for
writers
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
6
Readers/Writers: Example

thread A
thread B
thread C
Lock.acquire()
Read data
Lock.release()
Lock.acquire()
Modify data
Lock.release()
Lock.acquire()
Read data
Lock.release()
thread D
thread E
thread F
Lock.acquire()
Read data
Lock.release()
Lock.acquire()
Read data
Lock.release()
Lock.acquire()
Modify data
Lock.release()
Maximizes concurrency
 Great! But how do we implement this?
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
7
Reader-Writer Locks

New synchronization operator:
reader-writer lock


Multiple readers, just one writer
Can be built with standard synch primitives

E.g., semaphores
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
8
Readers/Writers Algorithm

As long as there are
no writers


Let readers in
If no readers or
writers

Let one writer in
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
9
Readers/Writers Algorithm

As long as there are
no writers


Let readers in
If no readers or
writers

Let one writer in
reader
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
10
Readers/Writers Algorithm

As long as there are
no writers


reader
Let readers in
If no readers or
writers

Let one writer in
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
11
Readers/Writers Algorithm

As long as there are
no writers


reader
Let readers in
If no readers or
writers

Let one writer in
reader
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
12
Readers/Writers Algorithm

As long as there are
no writers


Let readers in
reader
reader
If no readers or
writers

Let one writer in
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
13
Readers/Writers Algorithm

As long as there are
no writers


reader
Let readers in
reader
If no readers or
writers

Let one writer in
reader
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
14
Readers/Writers Algorithm

As long as there are
no writers


Let readers in
If no readers or
writers

reader
reader
reader
Let one writer in
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
15
Readers/Writers Algorithm

As long as there are
no writers


reader
Let readers in
reader
If no readers or
writers

reader
Let one writer in
writer
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
16
Readers/Writers Algorithm

As long as there are
no writers


reader
Let readers in
If no readers or
writers

reader
Let one writer in
writer
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
17
Readers/Writers Algorithm

As long as there are
no writers


reader
Let readers in
If no readers or
writers

reader
Let one writer in
writer
writer
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
18
Readers/Writers Algorithm

As long as there are
no writers


Let readers in
If no readers or
writers

reader
Let one writer in
writer
writer
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
19
Readers/Writers Algorithm

As long as there are
no writers


Let readers in
If no readers or
writers

Let one writer in
writer
writer
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
20
Readers/Writers Algorithm

As long as there are
no writers


writer
Let readers in
If no readers or
writers

Let one writer in
writer
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
21
Readers/Writers Algorithm

As long as there are
no writers


writer
Let readers in
If no readers or
writers

Let one writer in
writer
reader
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
22
Readers/Writers Algorithm

As long as there are
no writers


Let readers in
If no readers or
writers


writer
Let one writer in
What happens next?
writer
reader
reader
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
23
Starvation Problem
Two possible policies:

No reader waits unless writer is already in
Waiting writer always gets served first
1.
2.
Both variants may lead to starvation



First: writers may starve
Second: readers may starve
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
24
Readers/Writers Algorithm

As long as there are
no writers


writer
Let readers in
If no readers or
writers

Let one writer in
variant 2

How to avoid starvation?
writer
variant 1
reader
reader
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
25
Implementing R/W Locks

Can implement with two semaphores



“Mutex”: protect number of readers
“Queue”: control scheduling of writers
Control access to a “database”


int getValue()
void setValue (int n)
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
26
Implementing R/W Locks
class RWDatabase {
private Database db;
private int readers;
private Semaphore mutex;
private Semaphore writersSemaphore;
RWInt() {
readers = 0;
mutex = new Semaphore (1);
queue = new Semaphore (1);
}
int read() { … }
void write (int n) { … }
};
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
27
Implementing R/W Locks
void RWDatabase::write (int v) {
writersSemaphore.wait();
Write value
db.setValue(v); // Write the value
writersSemaphore.signal();
};
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
28
Implementing R/W Locks
int RWDatabase::read() {
int v;
mutex.wait();
readers++;
if (readers == 1) { // I’m first reader
writersSemaphore.wait();
}
mutex.signal();
v = db.getValue();
mutex.wait();
Read,
readers--;
if (readers == 0) { // I’m last reader
writersSemaphore.signal();
}
mutex.signal();
return v;
};

Add a reader
remove reader
Who can starve?
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
29
Problems with
Semaphores & Locks


Much better than load/store
Still many drawbacks

Serve two purposes



Mutual exclusion
Scheduling constraints
Effectively shared global variables



Access to semaphores may be anywhere
Not structured
Not tied to data they control access to
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
30
Monitors

Invented by C.A.R. “Tony” Hoare for Mesa


Also invented quicksort, “Hoare triples”
{a > 16} a = sqrt(a); { a > 4 }
monitor = Java class with:


All data private
All methods synchronized
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
31
Implementing Monitors in Java
class QueueMonitor {
private queue q;
public void synchronized add (Object item) {
q.add (item);
}
public Object synchronized remove() {
if (q.notEmpty()) {
Object o = q.remove();
return o;
} else {
// what should we do here?
}
};
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
32
Remove Options

Options for remove when queue empty:




Return special error value (e.g., NULL)
Throw an exception
Wait for something to appear in the queue
Wait = sleep()

But sleep inside synchronized…



Holds lock
Goes to sleep
Never wakes up!
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
33
Condition Variables

Queue of threads waiting in critical section


wait(Lock l)



Atomically releases lock, goes to sleep
Reacquires lock when awakened
notify()


Thread must hold lock when performing operations:
Wakes up one waiting thread, if any
notifyAll()

Wakes up all waiting threads
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
34
Implementing Monitors in Java
class QueueMonitor {
private queue q;
public void synchronized add (Object item) {
q.add (item);
notify();
}
public Object synchronized remove() {
while (q.empty()) {
wait();
}
return q.remove();
}
};
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
35
R/W Locks in Java
class RWDatabase {
private Database db;
private int readers;
private int writers;
RWInt() {
readers = 0;
}
public synchronized int read() { … }
public synchronized void write (int n) { … }
};
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
36
R/W Locks in Java
public int RWDatabase::read() {
preRead(); int v = db.getValue(); postRead();
return v;
};
private void synchronized preRead() {
while (writers > 0)
wait();
readers++;
}
private void synchronized postRead() {
readers--;
if (readers == 0)
notify();
}
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
37
R/W Locks in Java
public synchronized void RWDatabase::write (int v) {
preWrite(); db.setValue(v); postWrite();
}
private void preWrite() {
writers++;
while (readers > 0)
wait();
}
private void postWrite() {
writers--;
notify();
}
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
38
Summary

Reader-Writer Locks



Monitors


Permit concurrent reads
Implementable with semaphores
Classes: tie data, methods with synchronization
Condition Variables


Release lock temporarily
Waiting inside critical sections
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
39
Next Time

Deadlock
UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science
40