CS533 Concepts of Operating Systems Class 2a Monitors.
-
Upload
clifford-ball -
Category
Documents
-
view
220 -
download
0
description
Transcript of CS533 Concepts of Operating Systems Class 2a Monitors.
CS533 Concepts of Operating Systems
Class 2a
Monitors
CS533 - Concepts of Operating Systems 2
But first …
… catch up from last timeo synchronization errors and Eraser
CS533 - Concepts of Operating Systems 3
Enforcing mutual exclusion
Assumptions:o Every thread sets the lock before accessing shared data!o 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 = 2 A = A+1 A = A*B Unlock Unlock
CS533 - Concepts of Operating Systems 4
Solutions to misuse (or no use) of locks
Solution 1 - detectiono use static or dynamic checking tools to help track down
misuses of locking primitives (synchronization bugs)o How much can you detect?
Solution 2 - preventiono have the compiler insert the synchronization primitives
for you automaticallyo Which errors can be prevented this way, and which
can’t?
CS533 - Concepts of Operating Systems 5
Solution 1: Checking tools (class 2 cont.) Eraser
o A dynamic checker that uses binary re-writing techniques
o Gathers an “execution history” of reads, writes and lock acquisitions
o 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 6
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
o Assume all locks are candidates for a variable ( C(v) is full)
o For each access take intersection of C(v) and locks held by thread and make these the candidate set C(v)
o If C(v) becomes empty, issue warning
CS533 - Concepts of Operating Systems 7
Improving the locking discipline
The standard approach produces many false positives that arise due to special cases:
Initializationo No need to lock if no thread has a reference yet
Read sharingo No need to lock if all threads are readers
Reader/writer lockingo Distinguish concurrent readers from concurrent readers
and writers
CS533 - Concepts of Operating Systems 8
Improved algorithm
virgin
exclusive
shared
sharedModified(race?)
rd, wrFirstthread
wr rd,newthread
wr, new thread
wr
rd
CS533 - Concepts of Operating Systems 9
What can’t it detect?
Deadlocks? Races that do not manifest themselves in this
particular execution run It can’t prove the absence of errors, it can only
show the presence of errors
CS533 - Concepts of Operating Systems 10
Solution 2: Monitors
Monitors employ two key concepts, both of which can be automated by a compiler:
o Encapsulation:• Local data variables are accessible only via the
monitor’s entry procedures (like methods)o Mutual exclusion:
• The entry procedures are treated as critical sections
CS533 - Concepts of Operating Systems 11
Two kinds of synchronization
Mutual exclusiono Only one at a time in the critical sectiono Enforced via a mutex locko Must ensure that critical section invariant holds before
releasing mutex Condition synchronization
o Wait (block) until a certain condition (stronger than the critical section invariant) holds
o Signal (unblock) waiting threads when the condition holds
CS533 - Concepts of Operating Systems 12CS533 - Concepts of Operating Systems 12
Invariant of a mutex
The mutex “invariant” is the condition that must be restored before:
o The mutex is released Example
o Invariant A=B • always holds outside the critical section
o Read side critical sections depend on invariant A=B holding for correctness of their code
o Write side critical sections update A and B, temporarily violating the invariant
• Must exclude read side critical sections• Memory is immutable from the point of view of readers
CS533 - Concepts of Operating Systems 13CS533 - Concepts of Operating Systems 13
Condition variables
Mutex locks allow threads to synchronize before accessing the data
Condition variables allow communication among cooperating threads
o Used in conjunction with a mutex locko Allows a thread in a critical section to wait for a condition
to become true or signal that a condition is trueAcquire mutex lock (enter critical section)…Block until condition becomes true (frees mutex lock)…Free mutex lock (leave critical section)
CS533 - Concepts of Operating Systems 14
Logical view of monitor structures
initializationcode
“entry” methods
yx
shared data
condition variablesmonitor entry queue
List of threadswaiting to
enter the monitor
Can be called fromoutside the monitor.Only one active at
any moment.
Local to monitor(Each has an associatedlist of waiting threads)
local methods
CS533 - Concepts of Operating Systems 15
Monitors in Practice
Can be implemented directly by the programmero Essentially just a programming conventiono Hoare presents the basic idea behind this
Can be supported via library primitiveso Programmers must follow a convention in their useo Pthreads is an example of this
Can be part of a programming language and supported directly by the compiler
o Compiler inserts code to acquire and release monitor locko Reduces programming errorso Mesa is a move toward this
CS533 - Concepts of Operating Systems 16CS533 - Concepts of Operating Systems 16
Library example: Pthread condition variables
pthread_cond_wait (condition,mutex) o Releases “mutex” and blocks until “condition” is
signaledo Note: must say which mutex you are associated with
pthread_cond_signal (condition)o Signals “condition” which wakes up a thread blocked
on “condition” pthread_cond_broadcast (condition)
o Signals “condition” and wakes up all threads blocked on “condition”
CS533 - Concepts of Operating Systems 17
Implementing mutual exclusion for monitors How can we implement mutual exclusion for
monitor procedures?
CS533 - Concepts of Operating Systems 18
Implementing mutual exclusion for monitors How can we implement mutual exclusion for
monitor procedures?o Will spinning locks work?
CS533 - Concepts of Operating Systems 19
Implementing mutual exclusion for monitors How can we implement mutual exclusion for
monitor procedures?o Will spinning locks work?o Will yielding locks work?
CS533 - Concepts of Operating Systems 20
Implementing mutual exclusion for monitors How can we implement mutual exclusion for
monitor procedures?o Will spinning locks work?o Will yielding locks work?o What if we don’t want active waiting?
CS533 - Concepts of Operating Systems 21
Implementing mutual exclusion for monitors How can we implement mutual exclusion for
monitor procedures?o Will spinning locks work?o Will yielding locks work?o What if we don’t want active waiting?
Idea 1 (assuming uniprocessor):o Disable interrupts during monitor procedures
CS533 - Concepts of Operating Systems 22
A Simple Example
Goal: to build a blocking mutex lock using monitors
o Monitor procedures are “acquire” and “release” Demonstrate use of interrupt disabling on a
uniprocessor to implement mutual exclusion within the monitor procedures
CS533 - Concepts of Operating Systems 23
Using monitors to build a blocking mutexBlocking_mutex:monitorBegin
busy:boolean;nonbusy:condition;busy:=false; // initial valueProcedure acquire() Begin
if busy then nonbusy.wait;busy:=true;
EndProcedure release() Begin
busy:=false;nonbusy.signal
End;End Blocking_mutex;
CS533 - Concepts of Operating Systems 24
Using monitors to build a blocking mutexBlocking_mutex:monitorBegin
busy:boolean;nonbusy:condition;Busy:=false; // initial valueProcedure acquire() Begin <----- disable interrupts
if busy then nonbusy.wait;busy:=true;
End <----- enable interruptsProcedure release() Begin <----- disable interrupts
busy:=false;nonbusy.signal
End; <----- enable interruptsEnd Blocking_mutex;
CS533 - Concepts of Operating Systems 25
Using monitors to build a blocking mutexBlocking_mutex:monitorBegin
busy:boolean;nonbusy:condition;Busy:=false; // initial valueProcedure acquire() Begin ----- disable interrupts
if busy then nonbusy.wait; <----- ????busy:=true;
End ----- enable interruptsProcedure release() Begin ----- disable interrupts
busy:=false;nonbusy.signal <----- ????
End; ----- enable interruptsEnd Blocking_mutex;
CS533 - Concepts of Operating Systems 26
Implementing condition variables
Waito Add process to queue of processes waiting on this conditiono Suspend processo Release monitor’s mutual exclusion
• Wake up / schedule next process trying to enter monitor• Reenable interrupts?
Signalo Wake up / schedule first process waiting on this conditiono Release monitor’s mutual exclusion by enabling interrupts?o Suspend yourself
• On what? … and how do you ever wake up again?
CS533 - Concepts of Operating Systems 27
Implementing mutual exclusion for monitors How can we implement mutual exclusion for
monitor procedures?o Will spinning locks work?o Will yielding locks work?o What if we don’t have atomic instructions?
Idea 1:o Disable interrupts during monitor procedures
Idea 2:o Use binary semaphores
CS533 - Concepts of Operating Systems 28
Building monitors from binary semaphores Dijkstra had invented semaphores a few years
beforeo They could be used for a blocking mutex lock in the
construction of monitors
See example in the Hoare paper
CS533 - Concepts of Operating Systems 29
Bounded buffer solution with monitorsprocess Producerbegin loop <produce char “c”> BoundedBuffer.append(c) end loopend Producer
process Consumerbegin loop BoundedBuffer.remove(c) <consume char “c”> end loopend Consumer
BoundedBuffer: monitorvar buffer : ...; nextIn, nextOut :... ;
procedure append (c: char) begin ... end
procedure remove (var c: char) begin ... end
end BoundedBuffer
CS533 - Concepts of Operating Systems 30
Bounded buffer solution with monitorsBoundedBuffer: monitorvar 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+1 Count := Count-1 signal(nonEmpty) signal(nonFull) end append end remove
end BoundedBuffer
CS533 - Concepts of Operating Systems 31
Alarm clock exampleAlarmClock: monitor Begin
now: integer;wakeup: condition;now := 0;Procedure wakeme(n: integer); Beginalarmsetting: integer;alarmsetting := now + n;While now < alarmsetting do wakeup.wait (alarmsetting);wakeup.signal; End;Procedure tick; Beginnow := now + 1;wakeup.signal; End;
End AlarmClock;
CS533 - Concepts of Operating Systems 32
Semantics of condition variables
How many blocked threads should be woken on a signal?
Which blocked thread should be woken on a signal?
In what order should newly awoken threads acquire the mutex?
Should the signaler immediately free the mutex?o If so, what if it has more work to do?o If not, how can the signaled process continue?
What if signal is called before the first wait?
CS533 - Concepts of Operating Systems 33
Subtle race conditions
Why does wait on a condition variable need to “atomically” unlock the mutex and block the thread?
Why does the thread need to re-lock the mutex when it wakes up from wait?
o Can it assume that the condition it waited on now holds?
CS533 - Concepts of Operating Systems 34
Different Monitor Semantics
How do the semantics of Hoare’s monitors compare to those of:
o the mutexes and condition variables described by Birrell?
o Pthreads mutexes and condition variables?o MESA monitors?
CS533 - Concepts of Operating Systems 35
Hoare vs. MESA Semantics for Wait
CS533 - Concepts of Operating Systems 36
Hoare semantics
What happens when a Signal is performed?o signaling thread (A) is suspendedo signaled thread (B) wakes up and runs immediately
Result:o B can assume the condition on which it waited now holdso Hoare semantics give strong guaranteeso Easier to prove correctness
When B leaves monitor, A can run.• Depending on how B resumes A it might resume execution
immediately or after some other process
CS533 - Concepts of Operating Systems 37
MESA Semantics What happens when a Signal is performed?
o the signaling thread (A) continues.o the signaled thread (B) waits.o when A leaves monitor, then B runs.
Issue: What happens while B is waiting?o can another thread (C) run after A signals, but before
B runs?o Can A subsequently invalidate the condition on which
B was waiting? In MESA semantics a signal is more like a hint
o Requires B to recheck the state of the monitor variables (the invariant) to see if it can proceed or must wait again
CS533 - Concepts of Operating Systems 38
Bounded buffer with Hoare monitorsBoundedBuffer: monitorvar 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+1 Count := Count-1 signal(nonEmpty) signal(nonFull) end append end remove
end BoundedBuffer
CS533 - Concepts of Operating Systems 39
Bounded buffer with MESA monitorsBoundedBuffer: monitorvar 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 while (Count = n) then while (Count = n) then wait(nonFull) wait(nonEmpty) end while end while
buffer[nextIn] := c c := buffer[nextOut] nextIn := nextIn+1 mod n nextOut := nextOut+1 mod n Count := Count+1 Count := Count-1 signal(nonEmpty) signal(nonFull) end append end remove
end BoundedBuffer
CS533 - Concepts of Operating Systems 40
Subtle Problems with Monitors
Many subtle problems arise with the use of monitors in real-world systems
There are several different solutions to some of these problems
o MESA monitor semantics differ from Hoare monitorso Many current implementations differ in subtle ways
from both MESA and Hoare monitors
CS533 - Concepts of Operating Systems 41
Deadlock
You can still deadlock via access to a monitor mutex
o If two or more monitors invoke each other’s entry procedures
Deadlock can also occur with condition variableso See nested monitor problem (p. 20) of Birrell’s tutorial
CS533 - Concepts of Operating Systems 42
Deadlock (nested monitor problem)
Procedure Get();BEGIN
LOCK a DOLOCK b DO
WHILE NOT ready DO wait(b,c) END;END;
END;END Get;
Procedure Give();BEGIN
LOCK a DOLOCK b DO
ready := TRUE; signal(c);END;
END;END Give;
CS533 - Concepts of Operating Systems 43CS533 - Concepts of Operating Systems 43
Deadlock
Deadlock is not good, but why is it better to have a deadlock than a race?
CS533 - Concepts of Operating Systems 44CS533 - Concepts of Operating Systems 44
Priority Inversion
Occurs in priority scheduling Starvation of high priority threads
Low priority thread C locks MMedium priority thread B pre-empts CHigh priority thread A preempts B then blocks on MB resumes and enters long computation
Result:C never runs so can’t unlock M, therefore A never runs
Solution? – priority inheritance- synchronization-aware scheduling- threads temporarily acquire the highest priority of any thread waiting for them
CS533 - Concepts of Operating Systems 45CS533 - Concepts of Operating Systems 45
Dangers of blocking in a critical section
Blocking while holding M prevents progress of other threads that need M
Blocking on another mutex may lead to deadlock Why not release the mutex before blocking?
o Must restore the mutex invarianto Must reacquire the mutex on return!o Things may have changed while you were gone …
CS533 - Concepts of Operating Systems 46
Spurious wake-ups and lock conflicts
Reader-writer locking example (page 15, Birrell)o Writers exclude readers and writerso Readers exclude writers but not readerso Good use of broadcast in ReleaseExclusive()o Results in “spurious wake-ups”o … and “spurious lock conflicts”o How could you use signal instead?
Move signal/broadcast call after release of mutex?
o Advantages? Disadvantages?