Experiences and Processes and Monitors with Mesa

1
Experiences and Processes and Monitors with Mesa

• Sources
• Experiences and Processes and Monitors with Mesa,
  Computer Science, Portland State University,
  CS533, spring 2006, Jeanie M. Schwenk
• Semaphores and Monitors High-level
  Synchronization Constructs, Kai Li, Computer
  Science department, Princeton University
• B. Lampson and D. Redell. Experience with
  processes and monitors in Mesa. Comm. ACM 23, 2
  (feb 1980), pp 106-117.

2
Synchronization Constructs

• Semaphores
• Introduced by Dijkstra in 1960s
• Main synchronization primitives in early
  operating systems
• Monitors
• Monitors were first introduced as a programming
  language construct
• Examples Mesa, Java (synchronized methods)
• Brinch-Hansen (73) and Hoare Monitor (74)
• Concept, but no implementation
• Requires Signal to be the last statement (Hansen)
• Requires relinquishing CPU to signaler (Hoare)

3
Evolution of Monitors

• Mesa Language (77)
• Monitor in language, but signaler keeps mutex and
  CPU
• Waiter simply put on ready queue, with no special
  priority
• Modula-2 (84) and Modula-3 (88)
• Explicit LOCK primitive
• Mesa-style monitor
• Pthreads (95)
• Started standard effort around 1989
• Defined by ANSI/IEEE POSIX 1003.1 Runtime library
• Java threads
• James Gosling in early 1990s without threads
• Use most of the Pthreads primitives
• Java virtual machine uses a "Wait and Notify"
  monitor. (It is also sometimes called a "Signal
  and Continue" monitor.)

4
Monitor Hide Mutual Exclusion

• Procedures are mutual exclusive

5
Condition Variables in A Monitor

• Wait( condition )
• Block on condition
• Signal( condition )
• Wakeup a blocked process on condition

6
Monitors

• Separate the concerns of mutual exclusion and
  conditional synchronization
• What is a monitor?
• One lock, and
• Zero or more condition variables for managing
  concurrent access to shared data
• General approach
• Collect related shared data into an object/module
• Define methods for accessing the shared data
• Monitors also define a programming convention
• Can be used in any language (C, C, )

7
Producer-Consumer with Monitors
8
Example A Simple Barrier

• Thread A and Thread B want to meet at a
  particular point and then go on
• How would you program this with monitor?

9
Using Semaphores as A Barrier

• Use two semaphores

10
Example Interrupt Handler

• A device thread works with an interrupt handler
• What to do with shared data?
• What if m is held by another thread or by
  itself?

11
Use Semaphore to Signal
12
Introducing Condition Variables

• Condition variables
• Support conditional synchronization
• Three operations
• Wait() Release lock wait for the condition to
  become true reacquire lock upon return (Java
  wait())
• Signal() Wake up a waiter, if any (Java
  notify())
• Broadcast() Wake up all the waiters (Java
  notifyAll())
• Two semantics for implementation of wait() and
  signal()
• Hoare monitor semantics
• Hansen (Mesa) monitor semantics

13
Coke Machine Example Monitor
Does the order of aquire/while()wait matter?
Class CokeMachine Lock lock int
count 0 Condition notFull, notEmpty
Order of release/signal matter?
CokeMachineDeposit() lock?acquire()
while (count n) notFull.wait(lock)
Add coke to the machine count
notEmpty.signal() lock?release()
CokeMachineRemove() lock?acquire()
while (count 0) notEmpty.wait(lock)
Remove coke from to the machine count--
notFull.signal() lock?release()
14
Hoare Monitors Semantics

• Hoare monitor semantics
• Assume thread T1 is waiting on condition x
• Assume thread T2 is in the monitor
• Assume thread T2 calls x.signal
• T2 gives up monitor, T2 blocks!
• T1 takes over monitor, runs
• T1 gives up monitor
• T2 takes over monitor, resumes
• Example

15
Hansen (Mesa) Monitors Semantics

• Hansen monitor semantics
• Assume thread T1 waiting on condition x
• Assume thread T2 is in the monitor
• Assume thread T2 calls x.signal wake up T1
• T2 continues, finishes
• When T1 get a chance to run,T1 takes over
  monitor, runs
• T1 finishes, gives up monitor
• Example

fn1() x.wait // T1 blocks // T1
resumes // T1 finishes
fn4() x.signal // T2 continues // T2
finishes
16
Tradeoff

• Hoare
• Claims
• Cleaner, good for proofs
• When a condition variable is signaled, it does
  not change
• Used in most textbooks
• but
• Inefficient implementation
• Not modular correctness depends on correct use
  and implementation of signal

• Hansen
• Signal is only a hint that the condition may be
  true
• Need to check condition again before proceeding
• Can lead to synchronization bugs
• Used by most systems (e.g., Java)
• Benefits
• Efficient implementation
• Condition guaranteed to be true once you are out
  of while !

CokeMachineDeposit() lock?acquire()
if (count n) notFull.wait(lock) Add
coke to the machine count
notEmpty.signal() lock?release()
CokeMachineDeposit() lock?acquire()
while (count n) notFull.wait(lock)
Add coke to the machine count
notEmpty.signal() lock?release()
17
Experiences and Processes and Monitors with Mesa

• What is Mesa?
• Mesa is a strongly typed, block structured
  programming language whose syntax is similar to
  that of Pascal. 1
• Besides being a language, it is essentially a
  scheduler for resources with one monitor per
  resource.
• Design Goals of Mesa
• Develop a model for controlling concurrency using
  monitors for
• 1) local concurrent programming
• 2) global resource sharing
• 3) replace use of interrupts

18
Other options for concurrency

• Considered but rejected
• Message passing
• deemed to be equal to monitors but the message
  passing would require more work to develop a
  message-passing scheme
• Shared memory
• It would not work on multiple processors
• Needed an additional preemptive mechanism (ie
  interrupts)
• Would need mutex
• If didn't use mutex, needed sempahore

19
Mesa Monitor Review

• Has procedures and global data
• Entry procedure(s) for asynchronous access
• To gain access to the critical section
• Must hold the lock
• Called from outside the monitor
• Internal procedure(s)
• Must hold the lock
• Is private
• Called from inside the monitor
• External procedure(s) (Hoare does not have)
• Non-monitor activity (not in critical section)
• Global data not seen outside the monitor
• global to the critical section but still private
  data

20
Problems Addressed by Mesa

• Not handled by other monitor papers
• 1. Dynamic process creation and destruction
• 2. Semantics of nested monitor calls
• 3. Defining the meaning of WAIT
• 4. Priority scheduling
• 5. Exception handling (e.g. aborts, timeouts)
• 6. Monitoring large numbers of small objects
• 7. I/O

21
1. Dynamic Creation of processes in Mesa

• New process is invoked concurrently with its
  caller (can be detached)
• Communicate with a process the same way you
  communicate with a procedure
• Can call with parameters
• Can return a value
• Subject to strict type checking
• No special declaration for a procedure that is
  invoked by a process
• Cost of creating/destroying is moderate (why?)
• Allows interprocess communication without much
  overhead.

22
2. Patterns of Deadlocks

• Single process deadlocks with self (recursive)
• Avoid recursive entry procedures
• Inside a single monitor 2 processes end up in
  WAIT, each waiting for the other to wake it up
• Typically a bug that needs to be corrected
• Cyclic dependency among monitors
• Impose partial ordering
• Monitor M calls N, and N then wait for a
  condition which can only occur when another
  process enters N thru M and makes the condition
  true.
• Break monitors into smaller parts

23
Problems with MonitorsNested Monitor Calls

• What happens when one monitor calls into another?
• What happens to CokeMachinelock if thread
  sleeps in CokeTruckUnload?
• What happens if truck unloader wants a coke?

CokeMachineDeposit() lock?acquire()
while (count n) notFull.wait(lock)
truck-gtunload() Add coke to the machine
count notEmpty.signal()
lock?release()
CokeTruckUnload() lock?acquire()
while (soda.atDoor() ! coke) cokeAvailable.wai
t(lock) Unload soda closest to door
soda.pop() Signal availability for
soda.atDoor() lock?release()
24
3. Meaning of WAIT

• If a caller has to wait in an entry procedure,
• It releases the lock (waiting process will need
  to reacquire it when it enters the monitor)
• If a monitor calls an internal procedure, the
  lock is NOT acquired or released because the lock
  is already held
• If wait is in one of the internal procedures, the
  lock is released

25
Mesa Style Monitor (Birrells Paper)

• Associate a condition variable with a mutex
• Wait( mutex, condition )
• Atomically unlock the mutex and enqueued on the
  condition variable (block the thread)
• Re-lock the lock when it is awaken
• Signal( condition )
• No-op if there is no thread blocked on the
  condition variable
• Wake up at least one if there are threads blocked
• Broadcast( condition )
• Wake up all waiting threads

26
Options of the Signaler

• "Signal and urgent wait". Intuitively, signalers
  should have priority over new procedure calls for
  access to the monitor. Rather than joining the
  monitor's entry queue. signalers are placed in
  the "urgent" queue when a (waiting) procedure
  exits (returns or waits) a signaler is restarted
  from the urgent queue. this defines "Hoare
  monitors".
• "Signal and return". Often "signal" operations
  occur immediately prior to procedure returns. In
  such cases it seems pointless to make signalers
  wait to do nothing by return. They might as well
  return from the monitor call immediately after
  signalling. this defines  "Brinch Hansen
  monitors".
• "Signal and Continue". Allow the signaler to
  continue a "signal" operation leaves a reminder
  that a process from the queue waiting on the
  condition variable should be restarted when the
  currently active monitor procedure returns or
  waits. This is "Mesa monitor".

27
Options of the Signaler

• "Signal and wait". The signaled process gains
  immediate access to the monitor. The signaler
  rejoins the set of processes awaiting entry to
  the monitor.
• "Automatic signaling".  This is a case where this
  is no "signal". Instead, whenever a monitor
  procedure returns or waits, each "waiting
  condition" is evaluated, if one is true, a
  process from the waiting queue associated with
  that condition is restarted and given control of
  the monitor.

• J. Howard, "Signaling in Monitors", IEEE
  International Conference on Software Engineering,
  pp 47-52 (1976)

28
3. WAIT continued

• Mesa
• WHILE NOT ltOK to proceedgt DO WAIT c ENDLOOP
• Results in an extra evaluation of the condition
  but there are no extra process switches and no
  constraints on when the waiting process can run
  after a notify
• Hoare
• IF NOT ltOK to proceedgt THEN WAIT c

29
3. WAIT summary

• Mesa a monitor procedure that is in a WAIT
  releases the lock.
• When control leaves the monitor, the invariant
  must be established
• before returning from monitor
• before doing a WAIT
• Whenever control enters the monitor, the
  invariant can be assumed.
• At the start of an entry procedure
• after a WAIT

30
Invariant processConditions Locks

• An invariant is a condition or relation that is
  true when the associated lock is being set.
• Once the lock is set, the invariant can be
  false. However, the code that holds the lock must
  reestablish the invariant before releasing the
  lock. 2

31
The Programming Idiom

• Waiting for a resource

• Make a resource available

32
Revisit the Motivation Example

• Can this be further improved?

33
Other Interesting Topics

• Exception handling
• What if a process waiting in a monitor needs to
  time out?
• Alternatives to resume a waiting process
• Timeout
• Abort
• Broadcast

34
4. Priority Scheduling The priority inversion
problem

• Three processes (P1, P2, P3), and P1 P3
  communicate using a monitor M. Now consider the
  following sequence of events
• 1. P1 enters M.
• 2. P1 is preempted by P2.
• 3. P2 is preempted by P3.
• 4. P3 tries to enter the monitor, and waits for
  the lock.
• 5. P2 runs again, preventing P3 from running,
  subverting the priority system.

35
4. Priority Scheduling

• Hoare's method allows more senior threads to
  obtain the lock
• Mesa does not so it has to have a way to ensure
  starvation does not occur
• Associate with each monitor the priority of the
  highest priority process which ever enters that
  monitor. Then when a process enters a monitor,
  its priority is temporarily increased.

36
5. Exception Handling

• UNWIND
• Procedure P1 calls P2, P2 calls P3,, up to Pn.
• If Pn generates an exception which is eventually
  handled by P1.
• Distinguished exception UNWIND is first
  generated, and each of P2, , Pn is given a
  chance to cleanup.

37
6. Monitored Shared Data Objects

• Examples file, database, external storage
• Want to be able to add and remove shared data
  objects as needed
• Access needs to be serializable
• To accomplish
• Single monitor per object
• Multiple monitor instances per object
• Monitored record
• Programmer specifies how to access the monitored
  record but Mesa's type system does not support
  this well

38
7. I/O Handling

• Problem Devices cannot wait on a monitor lock
• Solution a notify that does not acquire a lock
• A naked notify is a notify that causes an
  interrupt handler to take over so the actions can
  be atomic.

39
Equivalence

• Semaphores
• Good for signaling
• Not good for mutex because it is easy to
  introduce a bug
• Monitors
• Good for scheduling and mutex
• Maybe costly for a simple signaling

40
Summary/Conclusion

• Hoare monitor construct
• entry and internal procedures
• Mesa
• entry, internal and external procedures
• Hoare monitor
• Fixed number of monitors
• Does not handle exceptions
• Mesa
• Dynamic number of monitors - can grow and shrink
  as necessary
• A monitor can have an exception handler
  associated with it
• Can create dangling processes (can be a monitor)

41
References

• 1 http//www.apearson.f2s.com/mesacourse1.html
• 2 http//docs.sun.com/app/docs/doc/816-5137/6mba
  5vpl1?aview
• http//www.cis.temple.edu/ingargio/old/cis307s95/
  readings/monitor.html
• Modern Operating Systems 2nd edition, Andrew S.
  Tanenbaum
• http//msdn2.
• microsoft.com/en-US/library/ms22896428VS.8029.as
  px
• http//www.cs.mtu.edu/7Eshene/NSF-3/e-Book/MONITO
  R/monitor-types.html