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


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


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?


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?


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


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


Improved algorithm

virgin

exclusive

shared

sharedModified(race?)

rd, wrFirstthread

wr rd,newthread

wr, new thread

wr

rd


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


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


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


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)


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


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


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”


Implementing mutual exclusion for monitors How can we implement mutual exclusion for

monitor procedures?



monitor procedures?o Will spinning locks work?



monitor procedures?o Will spinning locks work?o Will yielding locks work?



monitor procedures?o Will spinning locks work?o Will yielding locks work?o What if we don’t want active waiting?



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


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


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;



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;



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;


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?



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


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


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


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


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;


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?


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?


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?


Hoare vs. MESA Semantics for Wait


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


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


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


end BoundedBuffer


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


end BoundedBuffer


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


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


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;


Deadlock

Deadlock is not good, but why is it better to have a deadlock than a race?


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


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 …


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?

cs533 concepts of operating systems class 2a monitors

Documents