cs533 – spring 2006 - jeanie m. schwenk experiences and processes and monitors with mesa what is...

CS533 – Spring 2006 - Jeanie M. Schwenk

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 sharing3) replace use of interrupts


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


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


Problems Addressed by Mesa

● Not handled by other monitor papers

1. Dynamic process creation and destruction2. Semantics of nested monitor calls3. Defining the meaning of WAIT4. Priority scheduling5. Exception handling (e.g. aborts, timeouts) 6. Monitoring large numbers of small objects7. I/O


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.


2. Patterns of Deadlocks

● Single process deadlocks with self (recursive)– Avoid recursive entry procedures

● 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

● Order dependent– Break monitors into smaller parts


3. WAIT defined

● If a caller has to wait in an entry procedure, – It signals with a Notify– It releases the lock (waiting process will need to

reacquire it when it enters the monitor)● If wait is in one of the internal procedures,

the lock is released● If a monitor calls an external procedure, the

lock is NOT acquired or released because the lock is already held


3. WAIT continued

● MesaWHILE NOT <OK to proceed> 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

● HoareIF NOT <OK to proceed> THEN WAIT c


3. WAIT summary

● Mesa: a monitor that is in a WAIT releases the lock.

● When control leaves the monitor, the invariant must be established:– before returning – before doing a WAIT

● Whenever control enters the monitor, the invariant can be assumed. – At the start of an entry procedure– after a WAIT


Conditions

● Condition.wait– Release monitor lock– Put process to sleep. – When process wakes up again, re-acquire monitor lock immediately.

● Condition.notify – Wake up (at some time in the future) some process waiting on the

condition variable (queue). ● Hoare's definition a process must run immediately

– If nobody waiting, do nothing. Signal is lost.● Condition.broadcast

– Wake all processes waiting on the condition variable (queue)– If nobody waiting, do nothing. Signal is lost.


Notify

● For resuming waiting processes● Really only a hint

– Signaler continues vs signal yields (Hoare)● Alternatives to attract the attention of a

waiting process– Timeout– Abort– Broadcast


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 never enters a monitor. Then when a process enters a monitor, its priority is temporarily increased.


5. Exception Handling

● UNWIND● Uses the procedure call process to control

the processing of exceptions – they either run concurrently or are separate processes (becomes the root process that must deal with an exception if it occurs)


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● <Some option I don't understand fully yet>● Monitored record

– Programmer specifies how to access the monitored record but Mesa's type system does not support this well


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.


Summary/Conclusion

● Hoare monitor construct: entry and internal procedures● Mesa: entry, internal and external procedures

● Hoare monitor– Fixed number of monitors– Does not handle excpetions

● 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)


Summary/Conclusion

● Hoare monitor– a waiting process can run when another monitor signals that

variable– signalling process runs as soon as the waiter leaves the

monitors (the signaling thread yields.)– the wait checks the invariant once (in an if statement) because

it assumes the lock still holds

● Mesa monitor– waiting process has to check condition to resume because

notify makes no guarantee of condition– the released thread yields the monitor– notify thread retains the lock and continues– The wait has to be checked in a loop


References

● [1] http://www.apearson.f2s.com/mesacourse1.html● [2] http://docs.sun.com/app/docs/doc/816-5137/6mba5vpl1?a=view● 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/ms228964%28VS.80%29.aspx● http://www.cs.mtu.edu/%7Eshene/NSF-3/e-Book/MONITOR/monitor-types.ht

ml


Invariant process:Conditions & 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]

cs533 – spring 2006 - jeanie m. schwenk experiences and processes and monitors with mesa what is...

Documents