by B. W. Lampson & D. D. Redell @ Xerox
CACM 1980
![]() |
Open
problems with monitor and answers this paper suggest
|
||||||||||||||||||||||||||||
![]() |
Why
monitor rather than non-preemptive scheduling or semaphore?
|
![]() |
Process
creation in Mesa: Any procedure call can be prefixed by 'fork', for
example, ReadLine(terminal) -> fork ReadLine(terminal)
|
||||||||||||||
![]() |
Processes in Mesa are treated exactly like any other value: they can be passed as arguments, assigned to variables, etc | ||||||||||||||
![]() |
Strict
type checking is possible:
|
||||||||||||||
![]() |
The cost of creating, destroying, and storing processes is moderate. Don't understand! | ||||||||||||||
![]() |
Java-like exception handling in Mesa -> Root procedure should catch all the exceptions -> Arbitrary procedure written for sequential call is NOT suitable for forking |
![]() |
Monitor
is an object comprised of:
|
||||||||||
![]() |
Only one process can be inside monitor and access the shared data | ||||||||||
![]() |
If the order of calling entry methods does matter, other provisions must be made in the program outside the monitor |
![]() |
A module in Mesa is exactly an object in OO | ||||||
![]() |
Monitor
modules:
|
||||||
![]() |
Condition variable: wait & notify | ||||||
![]() |
Mutex
will not be released when a process in monitor calls a (inside or outside)
function
|
![]() |
Kind of independent issue |
![]() |
Monitor is a tool for synchronization and it is the programmer's responsibility to be careful not to cause deadlock |
![]() |
But the tool has to provide a clear interface |
![]() |
Object are created and destroyed dynamically -> monitors for these objects should also be created and destroyed dynamically | ||
![]() |
In object oriented programming language such as Java, this is simply done by tagging an object as 'monitor' (actually tagging one or more function with 'synchronized') | ||
![]() |
But
this is a kind of headache in a non OO language
|
![]() |
If
|
||||||||
![]() |
how
to release the monitor lock that Pi has?
|
![]() |
'notify' instead of 'signal' |
![]() |
Timeout
|
||||
![]() |
Abort
|
||||
![]() |
Broadcast: wake all waiter instead of one waiter |
![]() |
Communication
between process and device--for example I/O device--can be implemented by
monitor
|
||
![]() |
Device can notify interrupt handler by naked notification that signals some event has happened | ||
![]() |
Called naked notify because the device has not hold monitor lock -> race condition can happen |
![]() |
Priority
inversion can occur
|
||||||||
![]() |
Monitor does not prevent priority inversion outright | ||||||||
![]() |
Proposed
and commonly used solution: priority boosting
|
![]() |
Pros: This paper deals with many aspects of monitors and provides solutions, almost all of which have blossomed at Java monitor |