1. Review The Critical Section problem Peterson’s Algorithm
Implementing Atomicity
Busy waiting
Blocking

2. Outline
Semaphores
what they are
how they are used
Monitors

3. What’s wrong with this picture?
Our solutions to CS have two unappealing features:
They are mistifying and unclear
They use busy waiting

4. Semaphores A semaphore consists of: A variable s A thread set T
A function P (Passeren; wait)
A function V (Vrijgeven; signal)
syntax example: Semaphore s(5);

5. Semaphore Operations
Initialization(val) {
s = val ;
T = ^; }

6. P(s) s--; if(s < 0) { add caller thread to T; block; }
This code executes atomically.

7. V(s) s++; if(s  0) { Remove a thread t from T; Unblock(t); }
This code executes atomically.

8. Mutual exclusion with semaphores
Thread T0
while (!terminate) {
<entry0> CS
<exit0>
NCS0 }
Thread T1
while (!terminate) {
<entry1> CS
<exit1>
NCS1 }
P(s);
V(s);
init: s = 1

9. Questions, Questions... What if we have n threads instead of 2?
What if we want to allow at most k threads in the CS?

10. Binary Semaphore Two types: Counting semaphores Binary semaphores
s takes any values
Binary semaphores
s takes only 0 or 1

11. Binary Semaphores P(s) V(s) if (s == 0) { Add caller thread to T;
Block; }
else
s--;
V(s)
if (T != ) {
Remove a thread t from T;
Unblock(t); }
else if (s == 0)
s = 1;

12. Important properties of Semaphores -I
Semaphores are non-negative integers
The only operations you can use to change the value of a semaphore are P() and V() (except for the initial setup)
Semaphores have two uses
Mutual exclusion: you know all about it
Synchronization: how do we make sure that T1 completes execution before T2 starts?

13. Important Properties of Semaphores- II
We assume that a semaphore is fair:
No thread t that is blocked because of a P(s) operation remains blocked if s is V’d infinitely often
Does this guarantee bounded waiting?
In practice, FIFO is mostly used, transforming the set into a queue.
V(s) never blocks.
Binary semaphores are as expressive as general semaphores (given one can implement the other)
But they are different:
{s = 0} V(s) V(s) P(s) P(s) VS
{s = 0} Vb(s) Vb(s) Pb(s) Pb(s)

14. Classic Problems: Producer-Consumer I
Producer adds items to a shared buffer
Consumer takes them out
Buffer avoids producers and consumers to proceed in lock step
Buffer is finite
Examples:
cpp|cc|as
coke machine
ready queue in a multithreaded multiprocessor ….

15. Producer Consumer II Two types of constraint:
Mutual Exclusion
Only one thread can manipulate the buffer at any one time
Condition Synchronization
Consumer must wait if buffer is empty
Producer must wait if buffer is full
Are these safety or liveness properties?

16. Producer Consumer III Use a separate semaphore for each constraint
Semaphore mutex; // protects the shared buffer
Semaphore fullSlots; // counts full slots: if 0, no // coke
Semaphore emptySlots; // counts empty slots: if 0, // nowhere to put more coke

17. Producer Consumer IV Is the order of Ps important?
Semaphore new mutex (1);
Semaphore new emptySlots(numSlots);
Semaphore new fullSlots(0);
Producer() {
P(emptySlots);
P(mutex);
put 1 coke in the machine
V(mutex);
V(fullSlots); }
Consumer() {
P(fullSlots);
P(mutex);
take a coke out
V(mutex);
V(emptySlots); }
Is the order of Ps important?
Is the order of Vs important?

18. Beyond Semaphores
Semaphores huge step forward (immagine having to do producer consumer with Peterson’s algorithm…)
BUT…Semaphores are used both for mutex and condition synchronization
hard to read code
hard to get code right

19. Monitors (late 60’s, early 70’s)
A programming language construct, much like what we call today objects
Consists of:
General purpose variables
Methods
Initialization code (constructor)
Condition variables
Can implement a monitor-like style of programming without without the language construct, using a combination of locks and condition variables

20. Locks A lock provides mutual exclusion to shared data: Rules:
Lock::Acquire() – wait until lock is free, then grab it
Lock::Release() – unlock; wake up anyone waiting in Acquire
Rules:
Always acquire before accessing a shared data structure
Always release after finishing with shared data structure
Lock is initially free

21. Example: Producer Consumer
addToBuff() {
lock.Acquire(); // lock before using shared data
put item on buffer, if there is space
lock.Release(); }
removeFromBuff() {
if something on buffer, remove it
return item;

22. Houston, we have a problem…
How do we change removeFromBuff so that it check if there is something in the buffer before trying to remove it?
Logically, want to suspend thread inside the critical section
What is the problem?
Solution: suspend and atomically release lock

23. Condition Variables
A queue of threads waiting for something inside the critical section (why does it not violate safety?)
Condition variables have two operations:
Wait()
Calling thread blocks, releases lock (gives up monitor)
Wait on a queue until someone signals variable
Signal()
Unblock someone who was waiting on the variable
Broadcast()
Unblock all waiting on the variable

24. Producer Consumer, again
addToBuff() {
lock.Acquire(); // lock before using shared data
put item on buffer
condition.signal();
lock.Release(); }
removeFromBuff() {
while nothing on buffer {
condition.wait(&lock)
remove item from buffer
return item;

25. A dilemma
What happens to a thread that signals on a condition variable while in the middle of a critical section?

26. Hoare Monitors Assume thread Q waiting on condition x
Assume thread P is in the monitor
Assume thread P calls x.signal
P gives up monitor, P blocks!
Q takes over monitor, runs
Q finishes, gives up monitor
P takes over monitor, resumes

27. Example: Hoare Monitors
fn1(…) …
x.wait // T1 blocks
// T1 resumes
// T1 finishes
fn4(…) …
x.signal // T2 blocks
// T2 resumes

28. Per Brinch Hansen’s Monitors
Assume thread Q waiting on condition x
Assume thread P is in the monitor
Assume thread P calls x.signal
P continues, finishes
Q takes over monitor, runs
Q finishes, gives up monitor

29. Example: Hansen Monitors
fn1(…) …
x.wait // T1 blocks
// T1 resumes
// T1 finishes
fn4(…) …
x.signal // T2 continues
// T2 finishes

30. Tradeoff Hoare Hansen Awkward in programming
Cleaner, good for mathematical proofs
Main advantage: when a condition variable is signalled, condition does not change
Used bymost textbooks
Hansen
Easier to program
Can lead to synchronization bugs
Used by most systems

31. Classic Problems 2: Readers-Writers
Motivation:
shared database (bank, seat reservation system)
Two classes of users:
readers (never modify database)
writers (read and modify database)
Want to maximize concurrency
at most one writer in database
if no writer, any number of readers in database

32. ar ≥ 0  aw ≥ 0  (aw = 0  (aw = 1  ar = 0))
Towards a solution
State variables:
ar --- active readers (readers in CS)
aw --- active writers (writers in CS)
Condition variables:
oktoread (readers can enter critical section)
oktowrite (writer can enter critical section)
Safety
ar ≥ 0  aw ≥ 0  (aw = 0  (aw = 1  ar = 0))

33. Structure of the solution
Database::read()
wait until no writers
access database
if no readers in database, let writer in
Database::write()
wait until no readers or writers
access database
wake up waiting readers and writers
Use procedures startRead, doneRead, startWrite, doneWrite

34. The procedures Database::startRead() { lock.Acquire(); while (aw) {
okToRead.Wait(&lock); }
ar:= ar+1;
okToRead.signal;
lock.Release();
Database::doneRead() {
ar :=ar –1;
if (ar =0) {okToWrite.signal}
Database::startWrite() {
lock.Acquire();
while (aw  ar) {
okToWrite.Wait(&lock) }
aw := 1;
lock.Release();
Database::doneWrite() {
aw := 0;
okToRead.signal;
okToWrite.signal;

35. Semaphores and Monitors - I
Can we build monitors using semaphores?
Try 1:
Wait() {P(s)} Signal() {V(s)}
Try 2:
Wait(Lock *lock) { Signal() {
lock.Release(); V(s);
P(s); }
lock.Acquire(); }

36. Semaphores and Monitors-II
Try 3:
Signal() {
if semaphore queue is not empty {V(s)} }
REMEMBER:
If a thread signals on a condition on which no thread is waiting, the result is a no-op.
If a thread executes a V on a semaphore on which no thread is waiting, the semaphore is incremented!

37. A few matters of style Always do things the same way
Always use monitors (condition variables plus locks)
Always hold lock when operating on a condition variable
Always grab lock at the beginning of a procedure and release it before return
Always use while (not if) to check for the value of a condition variable
(Almost) never use sleep to synchronize

38. Example: Java Each object has a monitor
User can specify the keyword “synchronized” in front of methods that must execute with mutual exclusion
Use Hansen monitors
No individually named condition variables (just one anonymous condition variable)
wait()
notify()
notifyAll()