1. CS533 Concepts of Operating Systems Class 3
Monitors

2. Enforcing mutual exclusion
Assumptions:
Every thread sets the lock before accessing shared data!
Every thread releases the lock after it is done!
Only works if you follow these programming conventions all the time!
Thread 1 Thread 2 Thread 3
Lock Lock
A = A = A+1 A = A*B
Unlock Unlock
CS533 - Concepts of Operating Systems

3. Solutions to misuse (or no use) of locks
Solution 1: use static or dynamic checking tools to help track down misuses of locking primitives (synchronization bugs)
Solution 2: have the compiler insert the synchronization primitives for you automatically
CS533 - Concepts of Operating Systems

4. Solution 1: Checking tools (class 2 cont.)
Eraser
A dynamic checker that uses binary re-writing techniques
Gathers an “execution history” of reads, writes and lock acquisitions
Evaluates consistency with rules
Is it enough to simply check that some lock is held whenever a global variable is accessed?
CS533 - Concepts of Operating Systems

5. Automated checking of conventions
Eraser doesn’t know ahead of time which locks protect which variables
It infers which locks protect which variables using a lock-set algorithm
Assume all locks are candidates for a variable ( C(v) is full)
For each access take intersection of C(v) and locks held by thread and make these the candidate set C(v)
If C(v) becomes empty, issue warning
CS533 - Concepts of Operating Systems

6. Improving the locking discipline
The standard approach produces many false positives that arise due to special cases:
Initialization
No need to lock if no thread has a reference yet
Read sharing
No need to lock if all threads are readers
Reader/writer locking
Distinguish concurrent readers from concurrent readers and writers
CS533 - Concepts of Operating Systems

7. CS533 - Concepts of Operating Systems
Improved algorithm
wr, new thread
virgin
rd, wr
First
thread
shared
Modified
(race?)
exclusive rd
rd,
new
thread wr wr
shared
CS533 - Concepts of Operating Systems

8. CS533 - Concepts of Operating Systems
Solution 2: Monitors
Monitors employ two key concepts, both of which can be automated by a compiler:
Encapsulation:
Local data variables are accessible only via the monitor’s entry procedures (like methods)
Mutual exclusion:
The entry procedures are treated as critical sections
CS533 - Concepts of Operating Systems

9. Two kinds of synchronization
Mutual exclusion
Only one at a time in the critical section
Condition synchronization
Wait until a certain condition holds
Signal waiting threads when the condition holds
CS533 - Concepts of Operating Systems

10. (Each has an associated list of waiting threads)
Monitor structures
initialization
code
“entry” methods y x
shared data
condition variables
monitor entry queue
List of threads
waiting to
enter the monitor
Can be called from
outside the monitor.
Only one active at
any moment.
Local to monitor
(Each has an associated
list of waiting threads)
local methods
CS533 - Concepts of Operating Systems

11. Implementing mutual exclusion for monitors
How can we implement mutual exclusion for monitor procedures?
CS533 - Concepts of Operating Systems

12. Implementing mutual exclusion for monitors
How can we implement mutual exclusion for monitor procedures?
Will spinning locks work?
CS533 - Concepts of Operating Systems

13. Implementing mutual exclusion for monitors
How can we implement mutual exclusion for monitor procedures?
Will spinning locks work?
Will yielding locks work?
CS533 - Concepts of Operating Systems

14. Implementing mutual exclusion for monitors
How can we implement mutual exclusion for monitor procedures?
Will spinning locks work?
Will yielding locks work?
What if we don’t have atomic instructions?
CS533 - Concepts of Operating Systems

15. Implementing mutual exclusion for monitors
How can we implement mutual exclusion for monitor procedures?
Will spinning locks work?
Will yielding locks work?
What if we don’t have atomic instructions?
Idea 1:
Disable interrupts during monitor procedures
CS533 - Concepts of Operating Systems

16. Using monitors to build a blocking mutex
Blocking_mutex:monitor
Begin
busy:boolean;
nonbusy:condition;
busy:=false; // initial value
Procedure acquire()
if busy then nonbusy.wait;
busy:=true;
End
Procedure release()
busy:=false;
nonbusy.signal
End;
End Blocking_mutex;
CS533 - Concepts of Operating Systems

17. Using monitors to build a blocking mutex
Blocking_mutex:monitor
Begin
busy:boolean;
nonbusy:condition;
Busy:=false; // initial value
Procedure acquire()
Begin <----- disable interrupts
if busy then nonbusy.wait;
busy:=true;
End <----- enable interrupts
Procedure release()
busy:=false;
nonbusy.signal
End; <----- enable interrupts
End Blocking_mutex;
CS533 - Concepts of Operating Systems

18. Using monitors to build a blocking mutex
Blocking_mutex:monitor
Begin
busy:boolean;
nonbusy:condition;
Busy:=false; // initial value
Procedure acquire()
Begin disable interrupts
if busy then nonbusy.wait; <----- ????
busy:=true;
End enable interrupts
Procedure release()
busy:=false;
nonbusy.signal <----- ????
End; enable interrupts
End Blocking_mutex;
CS533 - Concepts of Operating Systems

19. Implementing condition variables
Wait
Add process to queue of processes waiting on this condition
Suspend process
Release monitor’s mutual exclusion
Reenable interrupts
Wake up / schedule next process trying to enter monitor
Signal
Wake up / schedule first process waiting on this condition
Release monitor’s mutual exclusion?
Suspend yourself
On what? … and how do you ever wake up again?
CS533 - Concepts of Operating Systems

20. Implementing mutual exclusion for monitors
How can we implement mutual exclusion for monitor procedures?
Will spinning locks work?
Will yielding locks work?
What if we don’t have atomic instructions?
Idea 1:
Disable interrupts during monitor procedures
Idea 2:
Use binary semaphores
CS533 - Concepts of Operating Systems

21. Building monitors from binary semaphores
See example in paper
CS533 - Concepts of Operating Systems

22. Bounded buffer solution with monitors
process Producer
begin
loop
<produce char “c”>
BoundedBuffer.append(c)
end loop
end Producer
BoundedBuffer: monitor
var buffer : ...;
nextIn, nextOut :... ;
procedure append (c: char)
begin
...
end
procedure remove (var c: char)
end BoundedBuffer
process Consumer
begin
loop
BoundedBuffer.remove(c)
<consume char “c”>
end loop
end Consumer
CS533 - Concepts of Operating Systems

23. Bounded buffer solution with monitors
BoundedBuffer: monitor
var buffer : array[0..n-1] of char
nextIn,nextOut : 0..n-1 := 0
Count : 0..n := 0
nonEmpty, nonFull : condition
procedure append(c:char) procedure remove(var c: char)
begin begin
if (Count = n) then if (Count = n) then
wait(nonFull) wait(nonEmpty)
end if end if
buffer[nextIn] := c c := buffer[nextOut]
nextIn := nextIn+1 mod n nextOut := nextOut+1 mod n
Count := Count Count := Count-1
signal(nonEmpty) signal(nonFull)
end append end remove
end BoundedBuffer
CS533 - Concepts of Operating Systems

24. CS533 - Concepts of Operating Systems
Alarm clock example
AlarmClock: monitor
Begin
now: integer;
wakeup: condition;
now := 0;
Procedure wakeme(n: integer);
alarmsetting: integer;
alarmsetting := now + n;
While now < alarmsetting do wakeup.wait (alarmsetting);
wakeup.signal;
End;
Procedure tick;
now := now + 1;
End AlarmClock;
CS533 - Concepts of Operating Systems