CS 736 Reviews - Spring 2015

1. Summary
This paper addresses a number of problems that arise with the use of monitors for concurrent programming. Facilities for concurrent programming are introduced in Mesa to address these issue. Processes are treated as special procedure calls. Monitors provide synchronization to shared data. New semantics are introduced for notify and wait.

2. Motivation
The use of monitors for concurrent programming was not new but they had a number of issues such as:
1) fitting processes into the scheme of procedures
2) no. of processes and monitors is fixed at compile time and the degree of concurrency cannot be varied
3) issue arising with WAIT in a nested monitor call
4) exception handling
5) interaction of monitors and process priorities could lead to priority inversion
6) I/O devices were not part of the monitors synchronization framework
The authors address the above issues by introduces for concurrent programming in Mesa that can support a variety of quite large application programs,

3. Contribution
Mesa treats process creation as a special procedure activation that can execute concurrently with the caller. They are treated as first class values in the language, which can be assigned to a variable, passed as a parameter. This allows a greater flexibility in handling concurrency and the programmer can easily vary the degree of concurrency by simple creating new processes.
Mesa uses monitors to synchronize access to shared data. Processes can access shared data only within the body of monitor procedures. There are 2 kinds of monitor procedures: entry procedures which can called by processes from outside the monitor, and internal procedures which can only called from monitor procedures. The monitor ensures that only one process is executing within itself and the other process calling the entry procedure wait with the aid of monitor invariants.
Mesa redefines the semantics of WAIT and NOTIFY. In Hoare's definition of monitors requires that process waiting on a condition variable must run immediately when another process signals that variable. This requires several process switches whenever a process continues after wait. In Mesa, when a process which has defined the condition variable for which some other process may be waiting notifies the condition variable. This can cause execution of soe process waiting on the condition to resume at some convenient future time. Mesa introduces 3 alternative ways to NOTIFY to resume a waiting process: Timeout, Abort and Broadcast which allows more flexibility.

4. Evaluation
The paper summarizes the cost of processes and monitors relative to other basic Mesa constructs. The minimum cost of a Mesa module is 8 bytes of data and 2 bytes of code. Changing the module to a monitor adds 2 bytes each to code and data. While a procedure requires 8-byte activation record and 2 bytes of code, an entry procedure adds 8 bytes of code. Each condition variable occupies 4 bytes of data while WAIT and NOTIFY require 12 bytes and 3 bytes of code respectively. These costs are small compared to the code and data storage actually needed by typical monitors and procedures.
The execution time of calling and returning from a monitor entry procedure is about 70% more than an ordinary bare minimum call and return. The cost of WAIT and NOTIFY depends on the priority of processes involved but representative figures are 15 ticks for WAIT and 6 for NOTIFY. The authors state they have met their performance goals with the exception of FORK and JOIN as their cost is 38 times compared to a procedure call as they are only implemented in hardware.

5. Confusion
Did this paper originally introduce exception handling in nested monitor calls with the UNWIND mechanism?

1. Summary
This paper presents some insights of integrating processes and monitors into the Mesa language.

2. Problem
There are a number of problems not adequately dealt with in previous related works, including:

1. The semantics of nested monitor calls.


2. The various ways of defining the meaning of WAIT


3. Priority Scheduling


4. Handling of timeouts, aborts and other exceptions


5. Interactions with process creation and destruction


6. Monitoring large numbers of small objects

3. Contributions
The paper discusses the solution to those problems above in the following sections: (It is very hard to tell from the paper which part of the discussions is their own contribution! )

4. Evaluation
The paper evaluates the performance of their facilities by keeping track of program execution times and data stroage overhead. The paper concludes that their implementation met their efficiency goals.

5. Confusion

1. Do we have the concept of a monitor in our popular OSes today?


2. Did the paper solve the problem of page fault with the priority mechanism of Modula?

Summary: This paper introduces the design of concurrent support in the Mesa programming language. Mesa features a set of built-in synchronization support including monitors and condition variables. It also has native support for processes so as to making it easy to write concurrent programs in Pilot.

Problem:
1. Programming languages at that time did not have native support for synchronization.
2. Making programming language level synchronization support compatible with language features such as exceptions are challenging.
3. There were no good implementations for monitors or condition variables.
4. Synchronization primitives can conflict with priority scheduling.

Contribution:
1. Add language level support for processes and synchronization mechanisms. This can help making concurrent programming easier, and enable the OS itself to be written in Mesa.

2. Monitor modules. In Mesa a monitor is an instance of a module. It can have entry procedures, internal procedures, and external procedures. Entry procedures and internal procedures define critical sections, which means at any time only one process can execute code inside it. The difference is that, entry procedures can be called by other modules, but internal procedures can only be called by other procedures in the same module. External procedures are not protected by critical sections.

3. Condition variables. In the original Hoare's definition of monitors it requires the waiter to be called immediately after the call of signal. This requires additional process switches and a perfectly reliable signal mechanism. In this paper, the behavior of wait has been changed so that signal only acts a hint of waking up. There's no guarantee that other processes will not be executed before the waiter wakes up; and the waiter can be waked up with be condition not being established. In this design, the waiter is responsible for testing the condition after being waken up. This allows for much more flexibility in the behavior of the scheduler, and the resulting system is more reliable.

4. Solving the priority inversion problem by disabling interrupts when a process enters a monitor.

Evaluation: The authors measured the space requirements for basic structures and and time costs for some basic operations. They feel their implementation has met their efficiency goals.

Confusions: In the naked notify part, what is the wakeup-waiting switch?

Summary:

This paper describes the monitor implementation used by the designers of the Pilot operating system. The authors wanted to add concurrent programming facilities to Pilot and explored techniques that would allow them to reason about processes executing in parallel, mainly related to issues with synchronization and accessing shared data.

Problem:

The authors attempted to add parallel programming facilities to Mesa, the language that was used to build Pilot. Concurrent execution of threads and the issues that it entails is still a significant issue, especially with newer heterogenous systems that use GPUs and deal with TLP.

Contributions:

The authors built their concurrent programming semantics to match the general structure used by Mesa. This meant that their monitor was constructed like a module/object that has three types of procedures: entry internal and external.

Contrary to Hoare's definition of monitors, the notification that happens whenever a process signals a condition variable is treated like a hint and does not require the waiting process to execute immediately. This removed the constraint of having the waiting process run immediately and also reduced the number of context switches.

While this could lead to other processes acquiring the lock and executing, the authors argue that monitors are used for synchronization and shouldn't be used for scheduling.

They also added timeouts (to avoid indefinite waits), aborts (to remove a process from the waiting list) and broadcasts (that allowed a process to notify all waiting processes). These mechanisms allowed the authors to create a more general and flexible approach to process synchronization.

They implemented a priority boost wherein a process would execute with a higher priority (the monitors) to avoid priority inversion. Pilot has an interesting manner of dealing with I/O through monitors as well. A notified process does not need to acquire a lock.

Evaluation:

The authors provide some numbers to explain the space overhead for a process. Taken out of the historical context of the paper, it is hard to judge. They also show the extra overhead, in terms of latency, incurred by using their monitor system. An interesting aspect of this paper is that the authors also provide a few use cases to show how these primitives could be used.

Summary:
The papaer describes various challenges faced while implementing concurrency control through Monitors and condition variables. Enviroment used is Pilot operating system and procedures and modules of Mesa language. Monitors provide single point of entry to shared data.

Problem:
The main problem in hand was to design a concurrency facility for used by a large operating system to enable resource sharing, mutual exclusion etc. It was desired to integrate it to Mesa language. Authors decided to used Monitors as a method of sysnchronization and provide a flexible system with good semantics.

Contributions:
1. Monitor Implementation:
- Introduced monitor locks for process synchronization.
- three kinds of procedure: internal, public and entry
2. Condition variables: They help in scheduling
3. Nested Monitor Calls: Divides into two modules: M' and O. Calls to a monitor N must be done through O rather than M'. Since O does not contain any locks, deadlock issues is resolved.
4. Exception Handling through UNWIND mechanism.
5. Priority scheduling: Notifier gives hint to other waiting processes with no guarantees, waking process rechecks its conditions. Reduces number of context switches.
6. Naked Notify to communicate with I/O devices. Whenever a device needs attention, it simply NOTIFY a condition variable o ake up a waiting process.

Evaluation:
Evaluations have been demostrated for synchronization primitive, however no comparisons with counterparts have been done. Evaluations show that context switches are very fast. Procedure Call and return increased from 3 to 13 bytes. Monitor calls take 70% longer time while Fork-return took 38 times more time than a normal procesdure call-return.

Confusions:
Still confused a bit in naked Notify mechanism.

1.Summary
This paper discusses the experience gained in integrating processes and monitors for concurrent programming using Mesa language semantics. The authors discuss the flexibility of Mesa's constructs for procedure calling and process abstraction along with the problems they handle which involves timeouts/aborts, device interrupts, priority inversion and others. The implementation details along with some storage and execution measurement has been provided.

2.Problem
Even though lot of work has been published on synchronization and monitors, the authors claim that the problems still remain in concurrent programming and synchronization mechanisms. Some of the problems include WAIT in nested monitor calls, exception handling by processes in monitors and scheduling of priority inverted processes. The paper aims to solve these problems by providing flexible and programmable synchronization facilities embedded in their Mesa language semantics.

3.Contributions
Mesa monitors are instances of modules with collection of procedures and data. They act as a carrier to i) synchronization primitives, ii) shared data and iii) code accessing the data. New concurrent processes can be created with FORK and JOIN constructs. One contribution of the paper is the variants of procedures, monitors provide thus allowing the processes to have discretion on acquiring locks. Problem of priority inversion is handled by allowing the process in monitor to be given higher priority. They introduce Mesa semantics opposed to Hoare semantics where a NOTIFY acts as a hint to the waiting process to execute in the future. This provides performance boost as it implies fewer context switches. The paper also contributes a technique NAKED NOTIFY in the way they handle device interrupts for processes by allowing devices to directly access the shared data. Overall, the main contribution of the paper seems to be the enumeration of design challenges and experiences they faced while providing flexible synchronization benefits while maintain the correctness of concurrent programs.

4.Evaluation
The paper provides implementation details with Mesa integrated into compiler, runtime package and with some hardware support too. Storage costs for WAIT, NOTIFY constructs and condition variables is given. Cost for monitor procedures are given and WAIT, NOTIFY take less ticks than an entry procedure. However, FORK/JOIN takes significantly larger time as they are implemented in software.

5.Confusion
How does it apply to multicore programming where global sharing policies are needed?

1. Summary

This paper summarizes the design of the concurrent programming facilities of a new operating system, Pilot. In particular, these facilities are integrated into the Mesa programming language which is tightly coupled with Pilot.

2. Problem

Existing frameworks for concurrent programming failed to address a number of issues. Some of them are listed below.
a) Existing definitions of processes do not allow the communication between Mesa modules (which are something like objects)
b) The set of processes/monitors cannot be extended dynamically.
c) WAIT in a nested monitor call
d) There is no way to timeout or abort a process

Through addressing the above issues the aim is to build a system for the following purposes
1) Local concurrent programming - Allow an application to be implemented as a set of synchronized processes to exploit concurreny within application.
2) Global resource sharing - Allow multiple applications to run on the same machine and share resources (in particular the processor)
3) Replacing interrupts - Handle interrupts directly by waking up relevant processes instead of going through a separate interrupt mechanism.

3. Contributions

Process
---------
- A process in Mesa parlance seems to correspond to what we call as "threads" nowadays. The cost of creating and destroying a process is moderate.
- A new process can be created through the invocation of any procedure. A newly created process runs concurrently with the caller process. Thus, the caller is free to perform other computations.
- A caller may wait for a callee process through the JOIN statement. Else, a callee can also be a detached processes that never returns to its caller.
- A process is a first-class value in the language. It can be assigned to a variable or passed as a parameter. A dangling pointer may occur if there is a reference to a process that has terminated.

Modules
---------
- A Mesa module packages a collection of procedures and the data they operate upon. In this sense, they can be thought of as classes.
- There are public procedures that are visible to the external interface and private procedures that cannot be called from outside the module.

Monitors
---------
- A Monitor is said to be an instance of a module. I guess this means it extends the module "class". Monitors can be dynamically created by creating new instances of the Monitor module.
- A Monitor encapsulates shared data and provides synchronized access to the data through its procedures as the shared data can only be accessed through a monitor procedure and only one process can execute a monitor procedure at a time. This process is said to be in the monitor.
- An entry procedure needs an UNWIND handler to be specified in order for the lock on the monitor to be released and the invariant restored.
- Priority inversion can be averted by assigning to the monitor the priority of the highest priority process which enters the monitor.

Condition Variables
-------------------
- Unlike in Hoare's monitor, a process waiting on a condition variable does NOT run immediately when receiving a signal but instead resumes at some convenient time in the future.
- This means a process has to check the condition it was waiting on again when it acquires the lock to the monitor as another process may have executed before it.
- In exchange for this small inconvenience though, this mechanism allows for no extra process switches and imposes no constraint on when to run a waiting process.
- 3 other mechanisms (Timeout, Abort, Broadcast) are also suggested as additional ways to resume a waiting process other than signalling.

Java is apparently influenced by Mesa. Ideas like Classes and implicit monitors in Java seem to be inspired by similar Mesa constructs.

4. Evaluation

- Changing a normal procedure to a monitor entry procedure adds 8 bytes of code, however, this is insignificant compared to the size and execution time for typical applications.
- The cost of calling and returning from a monitor entry procedure is about 70 percent more than an ordinary call and return.
- However, the cost of a FORK / JOIN pair is about 38 times that of a procedure call. This is attributed to the implementation being in software

5. Confusion

- How is it possible to design a system such that there is no process waiting for a monitor lock?

Summary:
The paper describes the results in using monitors for achieving concurrency control in Mesa and the decisions which were made to realise the implementation.

Problem:
The key problem addressed in the paper is of synchronization of light-weight threads and describing Monitor semantics implemented in Mesa. One way for concurrency programming is non-preemptive scheduling, however it still has drawbacks. Locking using semaphores is also ineffective since the authors wanted to integrate with Mesa. To overcome the issues, the authors propose the semantics decisions for implementing monitors with Mesa.

Contributions:

Basics: Consisted of 3 types of abstraction procedure in monitors, entry which needs a lock and internal and external which do not need locks. This helps other code outside monitors to keep progressing. Simplifies programmer effort since locks are acquired when entering monitors explicitly.

Deadlocks: Mesa avoids recursive entry hence deadlocking when the function calls itself is avoided. Overall, deadlocks might occur in some cases but the Mesa provides ways to reason and resolve the deadlocks by ordering dependencies, or breaking monitors to smaller chunks.

Priority: Sometimes, when high priority process blocks on lower priority processes, so the implementation give temporary boost to the priority of the process which holds the monitor to the highest priority blocked process. This helps in avoiding deadlock.

Interrupts: The paper introduced naked notification system, i.e. notify without waiting for the lock so that devices can communicate with processes when certain events occur.

Evaluation:
In evaluation, the authors present a set of results of space requirement of data and code for using monitors in mesa. In terms of execution time, calling and returning from monitors take about 50 ticks, which was 70% more than regular function call. The authors say that Mesa monitors meets performance expectations and it does not involve a significant overhead. The performance section does not mention any comparison with other systems and hence is not elaborate.

Confusions:
If the notify wakes up multiple processes, what happens after multiple processes are woken up together?

Summary
The authors wanted to integrate concurrency into programming by integrating processes and monitors into the Mesa language. They describe the how processes can be created, how synchronization is achieved via monitors, deadlocks that may arise, use of conditional variables and finally associating priority with monitors. It is also explained how processes are maintained and how the compiler now understands syntactic constructs and provides checks.

Problem
While development of Pilot - an operating system written in Mesa, the authors wanted to include new facilities like global resource sharing, removing interrupts and local concurrent programming. Thus while incorporating these concurrent programming facilities into Mesa, they faced multiple issues. They realized that messages and monitors were similar under certain programming restrictions while under shared memory paradigm voluntary process switching by yielding was slow during time critical events like interrupts.

Contribution
Mesa allows new processes to be created via a procedure activation that runs concurrently with its caller. Parameters can also be passed to the new process in the same way as done for procedures. Special care needs to be taken to ensure that process variables are not to be used after the process is destroyed, as well as procedures must not return before the process is destroyed, if parameters were passed by reference to the process. A hierarchical exception handling mechanism is also in place. The main aim of monitors is to ensure synchronization of access to shared data. The data protected by a monitor can only be accessed via a monitor body. There is no deadlock avoidance mechanism but the paper suggests ways to locate deadlocks and mentions that the programmer must be careful. When one process establishes a condition for which another process is waiting, it informs the condition variable, which causes a process waiting on the condition to resume later after reevaluating the predicate to run. There are additional ways to resume a waiting process viz. by establishing a timeout, sending an abort or a broadcast message telling all processes to resume which are waiting on the condition. A priority is associated with each monitor which is equal to the highest priority process that enters the monitor. Any other process that enters the monitor, its priority is increased to that of the monitor.

Evaluation
Code size and execution time were evaluated for various instructions and it was determined that the execution time was 70% more than an ordinary call. However the authors claim that on the basis of these performance figures, Mesa language achieved the efficiency goals with the exception of fork and join as these language constructs were developed in software rather in the underlying machine.

Confusions
I was not very much clear on naked notify and why exactly were monitors and conditional variables better than semaphores (Condition variables, locks and monitors can be implemented using semaphores).

Summary:
This paper describes the implementation of Monitors in the Mesa programming language. Monitors are used as a general-purpose solution to concurrency by encapsulating the critical section shared code and data into a module and then letting processes call into this module through entry procedures. Several problems with existing concurrent programming frameworks have been solved such as WAIT in nested monitor call, exceptions, priority scheduling, etc.

Problem
Existing systems for concurrent programming had various issues and the authors resolved these issues in their implementation. These included building a general-purpose system such that processes and monitors can be created dynamically, composability of monitors, facilities for organizing the critical section into modules, exception handling, precise semantics of wait and notify and the problem of priority scheduling.

Contributions

The authors address the problems one by one. Processes can be created and controlled dynamically by using FORK/JOIN. Exceptions need to be handled explicitly inside every enclosing block of code to make sure the monitor invariant is maintained. They define the precise semantics of the wait and notify calls. Notify is used as a hint and processes that wake-up from wait need to explicitly check the condition to ensure whether it can proceed. This makes the system very flexible and causes avoidance of unnecessary context switches. They solve the priority inversion problem by letting the monitor code run at the priority of the highest priority process whichever enters that monitor. They avoid deadlocks by avoiding mutually-recursive monitors and hence imposing a partial ordering on resources.

Evaluation:
The authors measure the data and code storage overhead of monitors relative to other basic Mesa constructs, such as simple statements, procedures and modules. Changing the module to a monitor adds 2 bytes of data and 2 bytes of code. Changing normal procedures to monitor adds 8 bytes of code. Cost of calling and returning from a monitor entry procedure is 50 ticks, about 70 percent more than ordinary call and return. An instrumentation of the code to demonstrate the deadlock avoidance would have been helpful.

Confusion:
Currently in most of the systems I think monitors are not used. I would like to explore further that why semaphores are more frequently used than monitors.

Summary: This paper addresses the issues of concurrent programming in real OS by introducing experience of designs of Mesa. Example issues are semantics of nested monitor calls, various ways of defining wait, priority scheduling, handling timouts and interaction with process creation and destruction. Experiments on several applications are shown.

Problem: Concurrent programming should support the properties below: application can be easily implemented by coupled processes, resources are sharing by different applications, and device use should be handled by processes instead of interrupts. To support these properties, many design problems (programming structure, processes, monitors, WAIT, exceptions) should be addressed.

Contribution:
1. The design of monitor, which should do synchronization, sharing resources, interact with processes. In Mesa, monitors have three kind of methods: entry, internal and external.
External methods do not automatically lock the monitor, and is visible to other methods.
Internal methods assume the monitor lock is held, and are not visible to external methods.
Entry methods are visible to external methods and require to lock the monitor, they do automatical lock for simplicity.

2. The design of condition variables. Instead of the strict semantics and difficult implementation of previous work (e.g. Horae monitors), they use looser semantics.
It simplifies the wakeup process, don't do the strict check of the condition, but wake up whenever the condition may be true. It allows wakeups based on timeouts, allowing the processes to wait for a fixed time and then wakeup.

Evaluation:
1. Evaluation on the time cost of each operation: module, procedure, call + return, monitor, entry procedure, fork+join, condition variable, notify, wait.
2. Three applications of Mesa are shown: Pilot, a general-purpose OS on large personal computers; violets, a distributed database manager supporting replicated data files, and Gateway, internetwork gateway for packet networks.

Confusion: How are the exceptions used to avoid deadlocks?

Summary:
This paper introduces the facilities for concurrent programming in Mesa, which is implemented via monitors.

Problem:
They want to design concurrent programming facilities of Pilot to support local concurrent programming and global resource sharing ,and replace interrupts.

Contribution:
The author chooses the monitor scheme instead of message passing scheme to make the integration easier. Preemptive scheduling is chosen. They chose monitors instead of semaphores due to semaphore's little structuring discipline on concurrent programming. Mesa casts the creation of a new process as a special procedure activation that executes concurrently with its caller and a process is treated as a first class value. A detached process will never return a result to its creator. The exceptions will be handled according to the ordering established by procedure calls. Data is protected by a monitor and can only be accessed within the body of a monitor. There are 3 kinds of procedures including entry/internal/external. The entry procedures ensure that at most one process is in the monitor by acquiring/releasing locks. An entry procedure must establish the invariant before returning and a monitor procedure must establish it before doing a wait. There exist three patterns of deadlock. The paper also gives the definition of WAIT: When one process establishes a condition for which some other process may be waiting, it notifies the corresponding condition variable. Naked notify is avoided by providing wakeup-waiting switch in a condition variable.

Evaluation:
The paper gives the data of the storage overhead (data + code) and the execution time in a unit called tick. They don't compare it with other system.

Confusion:
The author mentions that the monitor procedures are written textually next to each other and next to the declaration of the protected data, so that a reader can conveniently survey all the references to the data. Can you explain the storage structure?

Summary:
This paper describes the development of a 'monitor' construct that work well with large applications, and mesa semantics for condition variables.

Motivation:
The authors felt that there was a lack of a generalized scheme for dealing with concurrency, especially in their case where they were dealing with large applications ( and an entirely new operating system). Even in cases which were covered by existing mechanisms, they say that there were sources of confusions regarding the exact implementation details, which they had to resolve.

Contributions:
-The most important contribution of the paper is the development of a monitor construct that is built right into the programming language.
-This enables programmers to use concurrency naturally and simplifies debugging concurrent programs.
-'Monitors' which are synchronization constructs are mapped to modules ( which are Mesa constructs for grouping together related code and data).
-The authors also explain how 'wait's are handled in monitors: by releasing the monitor locks on any wait within the monitor, but holding on to them on waits in other modules (which are called by monitors).
-This allowed them to minimize the number of points where the monitor will need to re-establish its invariant.
-The paper also discusses exception handling in monitors and the mechanism for this is mostly built on top of the existing 'unwind' handlers in Mesa- As long as the monitor entry procedure has a programmer defined unwind handler, the monitor lock is automatically released after the handler has executed (this is because of the assumption that the handler code would cleanup the shared state inside the monitor)
-The other major development in the paper is that of the 'Mesa semantics' for dealing with condition variables. This is looser than the earlier 'Hoare semantics' and allows for spurious wakeups (and hence over-signalling/broadcasting) of processes sleeping on condition variables.

Evaluation:
The paper compares the performance of sequential programs with concurrent programs using the newly developed monitor constructs to give an idea of the amount of overhead involved. The authors argue that (for mechanisms other than fork and join - which they say are rarely used compared to the others) the storage/processing overheads of their concurrency mechanisms are not significant compared to the size and execution time for most major applications.

Confusion:
Are Hoare semantics in use in any major operating systems (general purpose/otherwise) currently? Are there any studies that compare the implementation of mesa and hoare semantics to evaluate their performance?

1. summary
This paper describes design and implementation of concurrency control facilities using monitors in Mesa programming language. Beginning with the issues that can arise with the use of monitors in a real world system, author provides solutions to those issues while reasoning the design choices made during the process.
2. Problem
A number of problems arise when using monitors such as: the semantics of nested monitor calls; the various ways of defining the meaning of WAIT; priority scheduling; handling of timeouts, aborts and other exceptional conditions; interactions with process creation and destruction; monitoring collection of small objects. These problems are addressed by the facilities described in this paper for concurrent programming in Mesa.
3. Contributions
a) Creation of process is treated as a special procedure that execute concurrently with its caller.
b) Monitors are instances of Mesa modules with a collection of procedures(entry, internal and external) and shared data.
c) Deadlocks arise when there is a cyclic dependency on call to entry procedures. This can be avoided by imposing a partial order on resources.
d) UNWIND exception is used to handle a abandoned entry procedure, which restores the monitor invariant and releases the lock before the procedure is destroyed.
e) Processes that are waiting on a condition variable, notify is regarded as hint and it causes one of the waiting process to be executed sometime in future. When the waiting process resumes it acquires the lock and reevaluates the condition condition before proceeding.
f) Alternatives to notify are also introduced, ie. timeout,abort and broadcast.
g) When priority scheduling is used, priorities may be subverted by monitors. To avoid this, each monitors are associate with the priority of the highest priority process which ever enters that monitor.
4. Evaluation
The authors provide storage cost for monitor modules, entry procedures, fork/join, and compare them to that of standard modules, procedures, and call/return. These storage cost are small when compared to actual storage costs of a typical module. For comparing the execution times author defines ticks(time to execute a simple instruction). Fork/join pair ,wait, notify and monitor procedure's execution times are compared with the respective primitives. Fork/join execution time is longer since it has been implemented in software rather than the underlying hardware. The author has also implemented 3 systems(Pilot(OS), Violet(DB) and Gateway(network forwarder)) using the proposed synchronization mechanism to showcase its application and efficiency.
5. Confusion
Did not understand the concept of naked notify and monitored records completely.

Summary:
This paper addresses the problem in using of monitors for concurrent programming facilities in Mesa, a language used for writing Pilot operating system.

Problem:
Use of monitors as synchronization primitives has problems like semantics of nested monitor calls; defining WAIT; priority scheduling; handling timeouts, aborts and other exceptional conditions; interactions with process creation and destruction; monitoring large number of objects. In non-preemptive scheduler, mutual exclusion is ensured between yield points. However in preemptive scheduler, monitors are considered in comparison to semaphores since semaphores exert little structuring discipline on concurrent programs.

Solution:
The requirement of facilities implementation in Pilot are: Local concurrent programming, global resource sharing, and replacing interrupts. Use of synchronization primitives addresses them. Key solution features are:
-new processes are cast as special procedure activation that executes concurrently with its caller. A process is dynamic and can easily detach/abort from caller.
-two monitor procedures: entry procedures and internal procedures. processes perform operations on data by calling entry procedures only.
-simplest monitor is a module, a unit of global program structuring.
-programmer has to take care of avoiding deadlocks due to monitor use, that can occur due to ex. WAIT by two process simultaneously in a single monitor.
-WAIT semantics and condition variables:a process establishes a condition for which some other process may wait, it notifies the corresponding condition variable.
-priority: each monitor maintains a priority of highest priority process that enters it

Evaluation:
Basic evaluation is done in terms of storage costs and execution time in comparison to sequential constructs. The cost of storage is small compared to actual modules and procedures storage requirements. But, cost of calling and returning from a monitor is about 70% more than an ordinary call.

Concerns:
none at the moment

Summary
The paper talks about the integration of processes and monitors into the Mesa language so as to support concurrent programming on Pilot, an operating system developed by the authors. It also explains how monitors,condition-variables can be used to synchronize and share data among concurrent processes and thereby serialize the operations on shared data.
Problem
They were looking for a general solution to concurrency. They wanted to have a flexible solution to general problems of dynamically creating processes, terminating processes etc. They were specifically looking to solve the problems of a system programmer rather than the applications. They were interested in integrating the concurrency into the language instead of as a library. They also wanted programmability. They wanted an easier to use solution to concurrency. Another problem they wanted to solve was to provide fine grain locks without being error or deadlock prone.
Contributions
Mesa allows to invoke any procedure as a new process without any special declaration. Hence method of passing parameters to a new process and retrieving its results is exactly like that of the normal procedures. A process is like a value which can be assigned to a variable,or an array element and in general treated exactly like any other value. In Mesa shared data is protected by a monitor module and can only be accessed by processes through entry procedures. Monitor ensures that utmost one process in executing a monitor procedure and any other process that calls the monitor will be delayed. Internal procedures(private) can be called only from procedures within the monitor;external(non-monitor procedures) can be called from anywhere. This way monitor modules reduce the effort needed by programmers to achieve mutual exclusion.To avoid deadlock, locks are released before generating an exception. Monitored objects help improve the maximum concurrency while maintaining other aspects of monitor as it is. Mesa provides UNWIND exception to allow cleanup before being destroyed when an exception occurs in a nested procedure call. NOTIFY signal is sent to all the processes waiting on a conditional variable. Provide ordering constraints through priority. Avoid problems of starvation by allowing the lock holder to have the highest priority as that of its waiters. They also extended monitors to deal with hardware interactions by condition variables. Instead of handling interruptions, hardware raises a condition and makes sure that high priority interrupt handlers run right away.
Evaluation
The authors tried to evaluate the performance in terms of the number 'ticks' for every operation.A normal procedure call and return would take 30ticks. Monitor call and return takes 50ticks. The numbers for other operations like process switch, WAIT, NOTIFY were also provided. The authors state that these number has met their goals with exception of fork and join. They also developed programs : an operating system, a calendar system and inter-network gateway to describe the way in which processes and monitors are used.
Confusion
I did not completely understand the concept of naked NOTIFY.

1. Summary

They describe an implementation of monitors meant to be use in Mesa, designed for ease of programming, while providing powerful primitives for parallel programming.

2. Problem

When using concurrency, one often some form of synchronization or mutual exclusion. But many of the existing systems are either of purely academic consideration, or not of sufficient flexibility to be used with ease in large systems.

3. Contributions

The core concept is that of a monitor. Which represents the collection of the synchronization primitives, shared data, and the code to interact with them. Within Mesa, monitors can be implemented as a module with certain additional structure. In particular, the methods within a mesa monitor are split into three types, Entry, Internal and External. External methods function as normal methods, and do not automatically lock the monitor, and are visible to other modules. Similarly with internal methods, except they generally assume that the monitor lock is held, and they are not visible to external modules. Most interestingly, the Entry methods are visible to external modules, and they require locking the monitor, but instead of requiring the user of the method lock on something, they automatically lock on the monitor.

The second major innovation is that of the condition variables. There had been other mechanisms to wait on conditions, notably the Horae monitors, but those in particular, required a very strict set of semantics, which were somewhat difficult to implement. Instead they used a system with looser semantics, in particular, allowing for spurious wakeups.

This innovation proves very powerful, most obviously it allows for the simplification of the wakeup process, instead of requiring a strict check that the condition required is true, it suffices to wake up anytime the condition may become true. Also, without this requirement of strict checks, we may also choose to wakeup all waiting processes rather than choosing one particular one, simplifying the wakeup logic. It also allows for wakeups based on timeouts, allowing for a thread to wait for some period of time before giving up.

4. Evaluation

Certainly they demonstrate that monitors can be implemented with low space overhead, but the performance overhead is more significant, with monitor calls taking >50% longer, and considering that by design the time spent inside a monitor function is likely to be short, this is a non-trivial consideration. Perhaps even more concerning was the 60 ticks it required to do a process switch, and considering that the worst case is a process switch every instruction, this merits some consideration. Now it may turn out that on the systems they design process switches are rare, but this has not been demonstrated.

5. Confusion

Why 3 and not 4 types of monitor methods, in particular, why not make the need to be locked on the monitor be orthogonal to the question of whether the function is publicly visible.

1. Summary
This paper descibes the process of adding and using monitors to the Mesa language, specifically for the Pilot operating system. The paper describes the issues that can arise with their use in a large real world project like Pilot and provides some evaluation of their performance.
2. Problem
Synchronized programming had a large number of outstanding problems listed by the authors, these include: Support for a dynamic number of processess and monitors. Exception handling inside of monitors (without losing invariance). Semantics of scheduling on a wait/notify call.
3. Contributions
The authors describe the implementation of monitors and how it relates to the development of a large software project like Pilot. Mesa's exception handling is covered, which allows the graceful unwinding of protected functions when an exception is thrown, both resetting state and releasing locks. They also talk about the concept of priority inheritance, to avoid the priority inversion problem where a high priority process is blocked by a low priority process holding a lock it depends on. The issue of scheduling for Mesa's monitors is also discussed, with the idea of using a while loop around a call to wait (which allows looser notification scheduling) instead of the Hoare model which requires a direct context switch upon notification.
4. Evaluation
The authors evaluate both the performance of their monitors and the usability they provide in a large software project like Pilot, which is mostly written in Mesa. The paper is less about direct comparison to other systems, and more a qualitative evaluation of the system the authors created.
5. Confusion
I'm not clear on the idea of the invariant needing to be established before leaving the monitor, such as when doing a WAIT.

Summary:
This paper is about design and implementation of concurrency control facilities in Mesa programming language in Pilot operating system. Concurrency facilities were implemented specifically for local concurrent programming, global resource sharing and replacing use of interrupts.

Problem:
Existing monitors had some notable problems and therefore not suitable for general purpose computing. There was no support for creation of dynamic synchronized process and number of monitors were fixed at compile time. Other problems were with semantics of nested monitor calls, priority scheduling and exception handling.

Contribution:
Main contribution of paper is efficient implementation of monitors in Mesa language and providing flexibility to developers. Data and procedures were encapsulated inside monitor, monitor also included lock and condition variables. Procedures were classified as internal, external and entry and access to shared data was provided with entry procedures only. Internal procedures were called from the monitor and user can call external procedures without acquiring any lock. By ensuring proper ordering of resources and non-recursive entry procedures some of the deadlock problem were avoided. To signal waiting process, authors defined NOTIFY in a different way. Notify acted as a hint for waiting process and waiting process need not to be run immediately. Once waiting process is resumed it has to check for condition variable again. This resulted in fewer context switch. Problem of priority inversion was solved by temporary increasing priority of process which is in Monitor. Naked notify helps in signaling waiting process for I/O without use of monitors. Unwind exception helps in restoring invariants, releasing locks and return with error.

Evaluation:
Paper doesn't evaluate implementation of monitors in Mesa with existing implementation of monitors. Use of monitors increase code and data size by few bytes only. Calling and returning took 70% longer while fork and returning took 38 times longer. Context switch were faster. Author claims results look impressive and they have implemented monitors efficiently.

Confusion:
Benefits of semaphore over monitor?

1. Summary
This paper uses the Pilot operating system and the Mesa programming language to highlight how synchronization and concurrency is achieved using monitors and addresses many issues encountered by old monitor implementations

2. Problem
Earlier implementations of monitors were unclear about the following issues:
1) Program Structure: It is hard to for processes to a scheme where processes are just modules in Mesa
2) Creating Processes: A set of fixed processes is not acceptable in a general purpose system
3) Monitor Creation: A fixed number of monitors is also unacceptable
4) WAIT in a nested monitor call
5) Exceptions: There has to be a mechanism for abandoning part of a sequential computation in an orderly way, and this must interact properly with monitors
6) Scheduling: Before no attention had been given to the interaction of monitors with priority scheduling of processes
7) Input/Output: Fitting I/O devices to monitors had not been worked out fully before

The paper strives to address most of the above issues

3. Contributions
The various contributions of this paper are mentioned below:
1) Processes: Mesa casts the creation of a new process as a special procedure activation that executes concurrently with its caller. It treats a process as a first class value in the language which can be assigned to a variable or an array element, passed as a parameter and in general treated exactly like any other value.
2) Monitors: A monitor ensures that at most one process is executing a monitor procedure at a time and this process is said to be in the monitor. Monitors have three kinds of procedures: entry, internal and external. The first two are the monitor procedures and execute with the monitor lock held.
3) Deadlocks: A deadlock usually happens inside a single monitor when two processes do a WAIT each expecting to be awakened by the other. A more subtle form of deadlock can occur if there is a cyclic calling pattern between two monitors.
4) Exceptions: Mesa allows the exception handler in a process to abandon the portion of the computation being done in the procedures it had called in sequence and continue execution. When this happens a distinguished exception called UNWIND is first generated and each of the called procedures is given a chance to handle it and do any necessary cleanup before its activation is destroyed
5) Condition variables: When a process establishes a condition for which some other process may be waiting, it notifies the corresponding condition variable. A NOTIFY is regarded as a hint to a waiting process; it causes execution of some process waiting on the condition to resume at some convenient future time. When the waiting process resumes, it will reacquire the monitor lock.
6) Naked NOTIFY: Communication with input/output devices is handled by monitors and condition variables much like communication among processes. When the device needs attention, it can NOTIFY a condition variable to wake up a waiting process; since the device does not actually acquire the monitor lock, its NOTIFY is called naked NOTIFY. The device finds the address of the condition variable in a fixed memory location.
7) Priorities: A way to avoid priority inversion is to associate with each monitor the priority of the highest priority process which ever enters the monitor. Then whenever a process enters a monitor, its priority is temporarily increased to the monitor's priority.

4. Evaluation
The cost of calling and returning from a monitor entry procedure is 50 ticks, about 70% more than an ordinary call and return. A process switch takes 60 ticks; this includes the queue manipulations and all the state saving and restoring. The speed of WAIT and NOTIFY depends somewhat on the monitor and priorities of the processes involved but representative figures are 15 ticks for a WAIT and 6 ticks for a NOTIFY. Finally, the minimum cost of a FORK/JOIN pair is 1100 ticks or about 38 times that of a procedure call.

5. Confusion
I do not understand the concept of monitored objects

Summary:
The paper provides a description of the concurrent programming facilities as a part of the Mesa programming language, which were developed using monitors as the underlying constructs used for mutual exclusion, signal-wait routines etc. The authors discuss various design choices considered and provide rationales behind the choices made. Finally, examples of applications showing the deployment of the design are provided where the authors discuss how each feature developed was used and what the challenges faced were.

Problem:
The problems that the authors were trying address was that that many aspects of use of monitors to manage concurrent processes were vague, for example, semantics of nested monitor calls, the WAIT routine, conditional variable etc. Also, the authors had to find a way to adapt the monitor constructs for the MESA language, which had a defined programming paradigm.

Contributions:
The cardinal contribution of the paper was defining the semantics of ‘monitor’. The authors chose an object-oriented kind of definitions where the monitor held data that was protected and the access to the data was provided through procedures. They defined three kinds of procedures- internal and entry, which resemble private and public methods in MESA and OO languages, and external procedure to give access to procedures outside the monitors. By making the entry procedure exclusive, the monitors automatically provide some form of synchronization. Also, entry and internal procedures execute with the monitor lock held, which again provides mutual exclusion for processes. The authors chose to deviate from the conventional principles of wait-signal routines by using NOTIFY, which doesn’t require the waiting procedure to resume immediately. This saves a lot of overhead since there is no need to make a heavy context switch in this case, the waiting procedure can continue when it’s actually scheduled. This mechanism is used today in pthreads implementation of wait-signal routines. The authors also ensure robustness from deadlock by imposing a few restrictions, such as partial ordering on resources etc. The authors also introduce monitor records, monitor objects with private locks, to provide exclusive access to multiple instances of same object. The UNWIND exception provided a safe way to handle exceptions, when a child procedure depended on a parent for exception handling. Naked Notify was used to communicate with I/O devices, which provided an elegant extension of the routines for procedures to I/O.

Evaluation:
The performance evaluation is provided in terms of ‘ticks’. The authors claim that the cost of monitor entry procedure was 50 ticks; a normal procedure call without any arguments or return value took 30 ticks. Costs of other primitives are also provided- WAIT=15 ticks, NOTIFY = 6 ticks, FORK/JOIN = 1100 ticks. Except the fork/join routines (which performed poorly because of software implementation), the whole implementation provided convincingly efficient performance. Along with this, storage overheads are also provided, some of which are monitor = 10B data and 4B code, fork/join= 2B data and 13B code etc. The numbers provided are convincing considering the amount of facilities added.

Confusion:
I didn’t quite understand the possible alternative use of ‘Abort’ instead of ‘Notify’.

Summary:
The paper provides a description of the concurrent programming facilities as a part of the Mesa programming language, which were developed using monitors as the underlying constructs used for mutual exclusion, signal-wait routines etc. The authors discuss various design choices considered and provide rationales behind the choices made. Finally, examples of applications showing the deployment of the design are provided where the authors discuss how each feature developed was used and what the challenges faced were.

Problem:
The problems that the authors were trying address was that that many aspects of use of monitors to manage concurrent processes were vague, for example, semantics of nested monitor calls, the WAIT routine, conditional variable etc. Also, the authors had to find a way to adapt the monitor constructs for the MESA language, which had a defined programming paradigm.

Contributions:
The cardinal contribution of the paper was defining the semantics of ‘monitor’. The authors chose an object-oriented kind of definitions where the monitor held data that was protected and the access to the data was provided through procedures. They defined three kinds of procedures- internal and entry, which resemble private and public methods in MESA and OO languages, and external procedure to give access to procedures outside the monitors. By making the entry procedure exclusive, the monitors automatically provide some form of synchronization. Also, entry and internal procedures execute with the monitor lock held, which again provides mutual exclusion for processes. The authors chose to deviate from the conventional principles of wait-signal routines by using NOTIFY, which doesn’t require the waiting procedure to resume immediately. This saves a lot of overhead since there is no need to make a heavy context switch in this case, the waiting procedure can continue when it’s actually scheduled. This mechanism is used today in pthreads implementation of wait-signal routines. The authors also ensure robustness from deadlock by imposing a few restrictions, such as partial ordering on resources etc. The authors also introduce monitor records, monitor objects with private locks, to provide exclusive access to multiple instances of same object. The UNWIND exception provided a safe way to handle exceptions, when a child procedure depended on a parent for exception handling. Naked Notify was used to communicate with I/O devices, which provided an elegant extension of the routines for procedures to I/O.

Evaluation:
The performance evaluation is provided in terms of ‘ticks’. The authors claim that the cost of monitor entry procedure was 50 ticks; a normal procedure call without any arguments or return value took 30 ticks. Costs of other primitives are also provided- WAIT=15 ticks, NOTIFY = 6 ticks, FORK/JOIN = 1100 ticks. Except the fork/join routines (which performed poorly because of software implementation), the whole implementation provided convincingly efficient performance. Along with this, storage overheads are also provided, some of which are monitor = 10B data and 4B code, fork/join= 2B data and 13B code etc. The numbers provided are convincing considering the amount of facilities added.

Confusion:
I didn’t quite understand the possible alternative use of ‘Abort’ instead of ‘Notify’.

Summary:
This paper addresses the issues of using monitors in the implementations of concurrent programming languages and then describes how processes, monitors and condition variables are implemented in Mesa and the rationale behind their semantics in addressing these issues.

Problem:
The motivation of the paper was to design a concurrent programming facility. The existing literature on the implementation of monitors at the time had several shortcoming, such as a fixed number of processes and monitors, possibility of deadlocks while waiting in a nested monitor call, problems in handling exceptions, scheduling problems like priority inversions, and handling IO in the framework of monitors and condition variables. A non preemptive scheduler was not feasible since it was too restrictive and semaphores were too simplistic and did not enforce a structuring discipline needed to solve the above mentioned problem.

Contributions:
1. A clearly defined implementation of a monitor as an instance of a module allowed Mesa to retain modularity in defining certain procedures as entry or internal(private) procedures which needed to be restricted by monitor locks. Procedures that did not have critical sections could be accessed as public procedures.

2. Nested monitor calls were handled by breaking a monitor M into two parts: a monitor M’ and an ordinary module 0 which provides an abstraction to M’ to access shared data. This prevents a certain deadlock condition that occurs in nested monitor calls.

3. By notifying waiting processes with only a hint and not providing any scheduling guarantees the implementation ensures that high level scheduling decisions are left to the user and there are no constraints enforced.

4. The UNWIND mechanism allows for intermediate procedures to clean up and restore the invariant by releasing the lock and return the appropriate error as opposed to being destroyed directly which could potentially cause a deadlock condition.

5. Monitored records help improve concurrency by providing a more granular lock on objects without the code duplication of separate monitor instances.

Evaluation:
The authors implemented processes and monitors by splitting various operations across three layers, namely the Mesa compiler, the runtime package and the machine, based on their frequency of use. The authors first tested the efficiency of process and modules against other constructs which showed minimal space and time costs for monitors over regular procedures except for fork and join which the authors felt they could implement in software. They then tested their performance on three Mesa programs: an OS, a calendar using replicated databases and an internetwork gateway program. This felt like a weak ending because the implementation details of these workloads did not add much to the evaluation.

Confusions:
I did not fully understand how monitored objects reduce code duplication?

1. Summary
The paper explains the theory and working of monitors which are one of the earliest implementations of critical regions in Operating Systems. The distinction between monitors and condition variables is clearly put forward and their implementation is explained in Mesa language for the Pilot operating system.

2. Problem
Earlier, a non-preemptive form of executing critical regions was imposed by the operating system. This was particularly less efficient for the following reasons:
a) Time critical events needed to implemented as only interrupts that are hard-bound to the system.
b) Any process with a critical-region and without a yield in it would not be called and not compiled.
c) It could be particularly worse during page faults and exceptions inside the critical region.
Thus, the authors wanted to implement a non-preemptive method of running critical regions with the same efficiency and correctness.

3. Contributions
a) Processes are created similar to forking in Unix and execute concurrently with its calling process.
b) Monitor procedures provide synchronization, protection of shared data and correct execution of critical sections.
c) The invariant(flag) is initialized at entry into the monitor. If another monitor is called from this monitor, it is executed as if it is a new call to the new monitor and invariants initialized accordingly.
d) Whenever a process enters a monitor, its priority is slightly increased so that t never waits on other low priority processes.
e) Condition variables are called using WAIT when waiting for a SIGNAL from another process. The waiting processes are blocked and put in a separate queue that is singled by the invoking process.
f) In addition to a signal to a particular process, CVs can be activated sing timeout, abort and broadcast from the signalling process.
g) I/O devices’ notify signals are not waiting on locks as they are time-critical and hence are called naked notify.

4. Evaluation
Since the authors do not have a ballpark to compare against, they provide some results of the runtimes it takes for different actions using micro-benchmarking. One interesting result is that monitor calls take 70% more time than a normal procedure call since it does initialization of the invariants. Also, the procedure fork+join takes 1100 ticks where 1 tick=time taken to run a simple instruction. To compare this, note that a normal procedure call takes 30 ticks and a monitor call takes 50 ticks.

5. Confusion
How correct is the naked notify? Does it always require the hardware to provide atomic updates to the shared region?

Summary :
This paper talks about how the authors developed an OS where they established synchronization between light weight processes (threads) using monitors and condition variables.

Problem :
To achieve mutual exclusion between processes, one way would be to implement non-preemptive scheduling. But this would restrict programming generality within critical sections; a procedure that is going to yield the processor cannot be called. These restrictions are not acceptable in highly modular systems. So, we need a preemptive mechanism for this. Semaphores can be a good way of doing this but they have no guarantees that acquired locks will be released. So, in this paper, the authors develop "monitors" using the MESA programming language to ensure concurrent programming and global resource sharing.

Contributions :
1. Implementing monitors using a condition variable and a lock requiring no further effort from the programmer for additional synchronization among the processes sharing the monitor. Monitor procedures can be
a. Entry - which are called to gain access to the monitor
b. Internal - which can only be accessed inside the monitor.
c. External - which can be called from anywhere.
2. When a process is signaled in the monitor, it is put on the ready queue instead of immediately running it. This ensures fewer context switches. Deadlocks are avoided by not using mutually recursive monitors, and enforcing partial ordering on resources.
3. To improve concurrent accesses, the authors use multiple monitor instances for the objects instead of one monitor handling many objects. They also use the MESA language to provide exception handling.

Evaluations :
The paper does not compare its running measures against any existing system. The authors provide the amount of data they need to implement monitors which is 2 bytes of data and 2 bytes of code to change a module to a monitor. Calling a monitor takes 70% more time than a regular function call. According to their benchmarks, the highest amount of time takes is for FORK+JOIN which is almost 40 times the time taken for a regular procedure call.

What I found confusing :
In a security aspect, programs which gained access to a critical section can do anything inside like changing protected variables, right? Wouldn't this impose additional overhead for the programmer to take care of shared variables and such?

1. Summary
In the paper, the authors describe their experiences adding concurrency primitive using monitors to Mesa, a programming language developed at Xerox PARC. Specifically, the authors address various issues pertaining to using monitors in real world setting, which were not adequately addressed by existing literature at that time, like nested monitor calls, interaction of scheduling priorities and monitors, monitoring large number of small objects, etc.

2. Problem
To make concurrent programming appealing in Mesa by adding first class primitives for process creation and destruction and for concurrency using monitors and condition variables.

3. Contributions
The primary contributions of this work relate to definition of primitives or meaning of processes, monitors and condition variables. Mesa equates creation of processes to something as simple as procedure invocations, i.e., any procedure in Mesa can be used as an entry point to newly created process (very similar to goroutines in Go). Mesa also lets easy synchronization, when the created process terminates by providing the join command, which when invoked in the parent process, waits for the created process to terminate. Mesa runtime handles the task of type checking and passing of procedure arguments to the newly created process.

Monitors and condition variables in Mesa provide a mechanism for
synchronization. Monitors encapsulates data, and provides entry procedures to
access and modify this data. At any given point in the time, only one process
can be in an entry procedure. Mesa defines a monitor invariant as means for
reasoning about the entry procedures and condition variable WAITs. A monitor
invariant is supposed to be established before returning from entry procedure or
WAITing, and a monitor invariant is expected at the start of entry procedure or
resuming from WAITs. In nested monitor calls in Mesa, the parent procedure still
holds the lock to the monitor. The authors reason of about various deadlocks
that can arise in monitors—in particularly ones due to nested monitor calls,
and discuss strategies to mitigate them.

4. Evaluation
The authors provide storage cost for monitor modules, entry procedures, and FORK+JOIN, and compare them to that of standard modules, procedures, and call+return. Similarly, the authors measure and provide cost in terms of execution time for various primitives included in Mesa like monitor procedure call+return, FORK+JOIN, WAIT, NOTIFY, etc. The authors implements three complex programs (OS, replicated database, and internetwork getaway) using these concurrency primitives to showcase the feasibility and ease of application programming.

5. Confusion
The locking mechanism in monitor records to solve the problem of monitoring large number of small objects is unclear.

1. Summary
The paper is primarily concerned with the subtleties of implementing and using monitors in real world applications. Monitors are a concurrency mechanism that deal with shared data where access to that data must be mutually exclusive. The use of monitors is prone to deadlock in some less than intuitive situations which the paper discusses in addition to providing some solutions. At the time there were no OOP languages, and Mesa is one of the first to go in that direction. Because of this, some sections of the paper describe how the modular nature or object-orientated aspects of Mesa benefit certain types of programs, specifically when it comes to concurrency and monitors.

2. Problem
Primarily the authors are concerned with the practicality of implementing monitors for a real world systems and discussing the issues that arise in such systems. They describe how monitors can introduce deadlock with recursive access, or cyclic access patterns where a monitor calls into a second monitor which calls back into the first. Later they note that monitors may interact poorly with priority scheduling, causing priority inversion. If a low priority process owns a lock on a monitor that a higher priority process is attempting to enter, it will effectively reduce the priority of the second process to that of the first.

3. Contributions
The authors’ description of their problems in implementing this monitor is their main contribution, demonstrating the feasibility of some past work on monitors. They also contribute the notion of priority inheritance where a process locking a monitor is temporarily promoted in priority to that of the highest priority process using that monitor. Additionally they point out how Mesa’s exception handling capabilities can play nicely with the monitor architecture, allowing monitor procedures to safely exit and restore locks after an exception occurs within the procedure or any nested procedure calls.

4. Evaluation
The paper presents some metrics for performance relating to the overhead of monitor procedure calls. Overall they regard their implementation as sufficiently performant and their results seem to support this conclusion.

5. Confusion
I believe most modern systems support some sort of recursive mutex, how is this implemented and, had this existed at the time, would its use have improved Mesa’s monitors?

1. Summary
In the paper, "Experience with Processes and Monitors in Mesa", the authors explain how to use monitors for concurrency programming and the issues that arise when they are used in real systems. The paper also describes the implementation of processes and monitors in Mesa, and provides some example applications using monitors.

2. Problem
The authors explain the issues faced while implementing Monitors to design a concurrency facility suitable for a large OS, Pilot – no dynamic process and monitor creation, deadlocks while waiting in a nested monitor call, problems with handling exceptions, priority inversion during scheduling of processes, including I/O in the framework of monitors and conditional variables, and bad program structure. They address these problems and implement monitors which fits into the semantics of Mesa programming language.

3. Contributions
1) Monitor modules: Defining Monitors as an instance of Mesa module with entry, internal and external procedures
2) Aborting a computation, handling exceptions: using a special unwind exception that allows processes to clean up, in particular, restore any monitor invariants before exiting
3) Avoiding Priority Inversion: temporarily boosting the priority of the holder of a monitor to the maximum priority of any process which would have earlier entered into the monitor
4) Avoiding Deadlocks: imposing a partial ordering on resources ie entering monitors in a particular order to avoid any mutually-recursive monitors
5) Notify semantics: In HOARE semantics, notify is a 'guarantee' requiring that a process waiting on a condition variable run immediately when another process signals that condition variable resulting in extra context switch. Mesa uses different semantics, where notify is like a ‘hint’, this causes the waiter to be executed some time in future. There is no guarantee that waiter executes right after notify avoiding extra context switching. Also defines alternatives to Notify namely Timeout,abort and broadcast

4. Evaluation
As part of the performance evaluation, the authors summarize the cost of processes and monitors relative to other basic Mesa constructs.
- Storage costs: changing the module to a monitor adds only extra 2 bytes of data and 2 bytes of code; changing the normal procedure to a monitor procedure adds only 8 bytes of extra code
- Execution costs: calling and returning from a monitor entry procedure is 50 ticks, about 70% more than an ordinary call and return; process switch takes 60 ticks including queue manipulation and state saving/restoring

5. Confusions
I did not clearly understand how Mesa solves the race condition which arises in Naked Notify.

Summary

Monitors are a powerful construct for concurrency: they provide both mutual exclusion and well as a mechanism to signal threads that their condition has been met. However, in real world usage these suffer from several implementation and design problems. This paper focuses on the Mesa programming language and the facilities it provides to overcome these issues; notably, a monitor scheme that provides synchronization and locking via entry procedures, and a WAIT/NOTIFY signal pattern allows passive scheduling on condition variables.

Problem

Monitors, while useful in theory, often struggled to meet the real-world needs of a wide variety of large size applications. Many existing implementations relied on a fixed set of processes at compile time, or a fixed number of monitors. There were a variety of ways to define a WAIT call, which led to difficult semantics for nested monitor calls. There was no handling for timeouts, aborts or exceptions. Finally, existing monitors generally favoured flexibility over an easily understandable structure, which confused programmers and often led to deadlock.

Contributions

The paper itself does not offer any contributions; rather, it examines the Pilot operating system and Mesa programming language and shows how these provide new facilities to deal with an older problem.

Evaluation

The authors evaluate processes and Mesa monitors under the Pilot operating system, the Violet distributed calendar system and an internet gateway forwarder. Mesa monitors were found to be generally very useful and manageable in Pilot, however it suffered from lack of mutual exclusion in interrupt handling as well as consistent signal handling. Violet seemed to work well, although it only required one monitor so is not as useful a study for evaluation. Similarly, the network gateway required only a single switch between a pair of processes. None of these evaluations contained any quantitative measures. This paper was more about describing and evaluating this new monitor implementation, rather than measuring against existing systems.

Confusions

I was generally confused by the priority scheduling problem described in Section 4. If these processes are using pre-emptive scheduling then how can P2 effectively block P3 from running?

1. Summary
This paper describes the experiences and challenges faced by the authors in implementing monitors in Mesa. It covers the choices the authors made in order to integrate monitors as a synchronization tool in Mesa semantics.

2. Problem
In order to provide concurrent programming capabilities in the Pilot operating system, the authors added support to the Mesa language itself. The problem discussed in this paper is the challenges that the authors faced in this task.

3. Contributions
The authors introduce how the process looks like in the Mesa programming environment. Mesa natively supports forking a new process and letting it run in parallel. Since forking the process is just invoking a procedure, arguments can be passed to the process and values can be returned back to the parent process. The monitors in Mesa have three types of procedures - entry, internal and external procedures. A lock has to be held while a process is in the monitor. The authors introduced a new monitored record constructor that includes a monitor lock and acts as the private data within the monitor. Monitors in Mesa use condition variables to wait on a condition until it becomes true. The signal coming from another process is only considered a hint and after wake up the process has to acquire the lock again. An exception to the normal case is a signal coming from a device driver process which sends a signal without acquiring the lock. The paper provides details of the implementation of monitors in the Mesa environment.

4. Evaluation
The paper presents a limited set of metrics that show the space requirements and execution time for the monitors. The authors also provide example applications - the Pilot operating system, a distributed calendar system and the network gateway that use monitors for synchronization. However, they do not show any performance metrics while monitors are in use in these applications.

5. Confusion
The part about the monitor having to establish the invariant before leaving it seemed confusing to me.

Summary - This paper shares insight gained while dealing with concurrent processes and using monitors for synchronization in Mesa for the Pilot OS. The authors describe the process abstraction in Mesa which is merely a special procedure call along with constructs to control concurrent processes, as well as the practical problems uncovered while adding support for concurrency such as timeouts, priority scheduling, exceptions and the implications of different semantics of WAIT and NOTIFY.

Problem - The authors claim that a large number of issues related to supporting synchronization techniques at the programming language level had not been resolved adequately by the research literature in this field. These include supporting a dynamic number of synchronized processes, ability to create monitors, dealing with WAIT calls inside nested monitor call, handling exceptions and aborts as well as reasonably providing priority scheduling in the presence of monitors.

Contributions - The main contribution of this paper is the practical discussion of the implications of various design decisions related to supporting concurrency. The paper discusses the support of creating and controlling concurrent processes through FORK/JOIN. The semantics of the NOTIFY call are changed to act as a hint rather than a confirmation of the truth of the monitor invariant. This improves performance by avoiding unnecessary context switches and allows flexibility regarding the choice of monitors to observe. The authors handle the problem of priority inversion by increasing the priority of the process holding the monitor to the highest possible. Various examples of deadlocks are discussed and solutions such as acquiring locks in a particular order are provided. Mesa also provides a naked NOTIFY, to improve the performance for cases of synchronization between processes running on devices with different frequencies.

Evaluation - The authors demonstrate the performance of Mesa’s synchronization facilities by reporting the data and code storage overheads of relevant constructs such as condition variables, WAIT, NOTIFY. Also, the execution time for these constructs is provided, with both WAIT and NOTIFY executing in under 15 times the execution time of a simple instruction. However, FORK+JOIN is a heavyweight construct which takes over 1100 times the execution time of a simple instruction, which the authors claim is a result of implementing it in software.

Confusions - Do you agree with the claim the authors make that in a well designed system, no process will be waiting on a lock? That doesn’t seem possible even in an idealistic system.

Summary:

The paper talks about monitors and how monitors have been used in Mesa semantics to achieve concurrency. Mesa redefines the creation of a process as a normal procedure and allows it to be passed around as a parameters or used as a value assigned to a variable. It removes the restriction of number of monitors by using monitored records.

Problems:

The current use and semantics of monitors had a lot of restrictions making it unfavorable in quite a number of situations especially in case of large applications. Some being processes shouldn’t be fixed at compile time and may be allowed to create during runtime, the number of monitors should not be fixed and must be able to increase based on the amount of data to synchronize, the problem of deadlock resulting from WAIT in nested procedure call and the like.

Contributions:

Mesa modifies the way a process is created slightly. It casts process creation as a procedure activation and thereby they can be created during runtime and passed around as a parameter or a value to a variable. The ordering of exception handling in case of nested procedures is the order that has been established by these procedure calls. If the procedure within which exception occurs doesn’t handle the exception it is propagated to the previous procedure which had called this procedure. The exception has to be handled finally by the root process if no one else handles it.

Provides two kinds of monitor procedures -
Entry procedure which lets external process to call into
Internal procedures which can be called only internally either by entry procedures or by other internal procedures.

The first thing the entry procedure does is to try to get the lock for the corresponding monitor. If not available, it is put in a wait queue. To execute in a monitor procedure it has to always hold the lock. The lock is released when the one holding it WAITs or completes its execution and also notifies the waiting process. The lock can be released only by the entry procedure or the corresponding internal procedures. According to Mesa semantics, when any process, waiting on a condition variable is notified it should recheck the state of the condition before proceeding. Mesa overcomes the problem of limited monitors by providing a monitor for each object. In case of notification between a device and a normal process, Mesa uses naked notify i.e., notify without acquiring a lock. But this gives rise to the possibilities of race conditions.

Evaluation:

Mesa clearly outlines the problems with the existing use of monitors and provides a well defined way to come out of it. Almost all the problems that might come up during synchronization have been addressed. They have even discussed about synchronization with external devices though not in detail.

Confusions:

Do they take care of lock release and notification if a process holding the lock is aborted? I would guess yes as some clean up has to be done if that lock is to be reused.

Summary – This paper describes use of monitors for concurrency programming. Among the main design goals that the authors try to achieve, one was to design and write programs that can run concurrently as well as take advantage of the inherent concurrent properties of the programs. Another allow programs to cooperatively share resources like the CPU (global resource sharing). All of the OS development and implementation was done using programming language.

Problem – Authors very clearly highlight several issues that arise while dealing with monitors in real time. They wish to tackle some of the below problems in concurrent programming using Mesa.
- Dynamic process creation and destruction
- Nested monitor calls could lead to deadlocks
- Defining the meaning of WAIT, how and when to release locks
- Priority scheduling was necessary as there were multiple processes and multiple processors
- Exception handling (e.g. aborts, timeouts)
- Monitoring large numbers of small objects (monitors and processes)
- I/O : read and writes must be atomic
To build a large system with many programmers and applications, module based programming was certainly aimed for.

Contribution
The number of monitors in Mesa can grow and shrink as necessary. A new process is created concurrently by the caller. A process can also be “detached” from its parent after creation. Monitor implicitly includes a condition variable and a lock, thereby requiring no additional synchronization among the processes sharing the monitor. Mesa won't prevent deadlocks but tries to provide an environment where the programmer can reasonably work around deadlocks. : Mesa monitors are non-recursive, hence an entry procedure can’t call itself or any other entry procedure of that monitor, thus avoiding a deadlock situation. The authors also suggest entering monitors in a particular order to avoid any mutually-recursive monitors In monitors, instead of immediately switching to a waiting process on a signal, the signaler places the waiting process on the ready queue and it continues to run. This will lead to a fewer context switches or not required. Condition variables have been extended to define for eg. notify() which is used instead of a signal, broadcast() which wakes up every thread that’s waiting on the condition, call to wait() can time-out. They also introduced naked notifies in which notify() can be done without holding the monitor lock.

Evaluation
The authors see that context switches are very fast but it didn’t really matter as all tests were done on uniprocessors systems. Code developed for condition variable led to an acceptable space overhead in Mesa. Procedure call’s cost increased to 13 bytes from 3 bytes for every fork call. Process creation was fast most of the time. Monitor calls took 70% longer while fork and return took 38times more time than a normal procedural call.

Confusion
I feel that the exceptions are not clearly explained and how they are being used to avoid deadlocks.

Summary
The paper talks about the monitor facilities that can be provided by Mesa, strongly typed - blocked structured programming language used to develop Pilot first, to handle various issues the author experienced while implementing model for concurrency using monitors in real systems. The paper also gives an overview of the semantics of processes, monitors and condition variables in Mesa.

Problems
The authors state the following possible issues which can be faced in using monitors and are still not addressed. The problems listed are - dynamic process creation/destruction, semantics of nested monitor calls, priority scheduling, exception handling, monitoring large numbers of small objects, priority inversion during scheduling of processes, including I/O in the framework of monitors and improper program structure. The authors have tried to address these problems and suggest approaches that can be incorporated in Mesa programming language.

Contribution
Few of the major contributions in the design of monitor and condition variables in Mesa are:
Dynamic creation/destruction of processes and monitors are made to handle exceptions
Notification: When a process establish a condition on which a different process is waiting, it notifies apt condition variable. It works like a “hint” - notifying process keeps the lock/control. It also notifies timeouts, aborts and broad casts. They also introduces naked notifies in which notify can be done without holding any monitor lock.
It avoids any priority inversion by inheriting the priority of the process that has entered the monitor.
Mesa monitors are non-recursive and tries to avoid deadlock.

Evaluation
The paper doesn’t present any evaluation details or comparison with other counterparts of Mesa. The paper do presents performance evaluations in terms of data and program storage. Context switch is very fast here. Calling and returning takes about 70% longer than original procedures while fork and return takes about 38 times longer than a procedure call which the authors find good enough.

Confusion
Is the Mesa model good for distributed memory systems or multi-core systems? What are the other counterparts of Mesa?

1. Summary
This paper introduces the design and implementation of pilot operating system written in Mesa. The focus is to provide flexible and powerful concurrency using monitors, addressing various issues such as nested monitor calls, semantics of WAIT, priority scheduling, exception handling, dynamic process creation and destruction, etc.
2. Problem
More and more applications try to improve efficiency by exploiting some level of concurrency, such as database and inter-network. A new concurrency model is needed to support local concurrent programming, global resource sharing and replacing interrupts. The problem arises when comparing and choosing existing solutions are not feasible due to the large size and wide variety of applications.
3. Contributions
Processes are treated as references and could be assigned to variables. It could be dynamically created and destroyed. New created process is executing concurrently with parent process and joins parent process when finished. Many new features such as dangling references/nested procedures are possible. Exception handling is done by forwarding to parent process until appropriately handled. When aborted, all nested cleanup are called in reverse order.
Shared data is protected by monitors that unifies synchronization, shared data and code of legal operations in the data. At anytime, at most one process could execute within monitor by calling entry procedure or invoking internal procedure. In Mesa, it is implemented as monitor modules which contains a set of related procedures in three kinds: internal, entry and external. The paper also discussed three types of deadlocks are involved in the monitor modules and provided possible solutions. To handle a collection of shared data, the paper introduced monitored record, which is an ordinary record with a monitor lock to protect shared data of a monitor.
In Mesa, processes waiting for a condition variable will notify the condition variable. A NOTIFY is a hint to eating process indicating that this process will resume in the future when condition is true. The lock should be released and reacquired upon waiting and resuming.
To prevent disorders in priority scheduling, Mesa grants the process highest possible priority if it is accessing the shared data and it could not be interrupted.
4. Evaluation
The paper measures the space overhead and time overhead for the new concurrent programming model. For each process, the data overhead and code overhead are roughly 50 bytes each, which is tolerable. The paper measures time overhead in terms of ticks/number of simple instructions. Fork and join take the majority of time of 1100 ticks. Other overhead totals in 150 ticks. I think this paper should provide more evaluations on some benchmark workloads to show that this overhead is worthwhile due to improvement in functionality and efficiency. For example, the paper can show the stability and flexibility is much improved by comparing various implementations of some workloads.
5. Confusions
The paper uses an example to show a public procedure Expand does not require lock in a storage allocator. I done understand why this is the case. In my opinion we need to lock the data before copy and release the lock after, otherwise we may copy the old data to new place which may be modified by some procedure during copying.

1. Summary
This paper introduces the mechanisms in Mesa to achieve high efficiency of concurrent programming, implementation details and performance evaluation.

2. Problems
The problems of monitor includes: fitting processes into defined interfaces; fixed number of processes at compile-time is not acceptable; a fixed number of monitors is also unacceptable; WAIT in a nested monitor call; handling exceptions; interactions between monitors and priority scheduling of processes and fitting I/O devices into the framework of monitors and condition variables. Parts of these problems have been addressed but are still limited. “Syntactic sugar” can alleviate some aspects of problems, however it is not enough.

3. Contributions
Define two kinds of monitor procedures: the entry procedures can be called from outside the monitor and the internal procedures can only be called from monitor procedures. The monitor ensures that at most one process is executing a monitor procedure at a time.

Mesa module is used to package a collection of related procedures and protect their private data from external access; Procedures in different abstractions do not need to access any shared data which helps reducing lock; Allowing an outside block to be written inside a monitor to solve the WAIT issue in a nested monitor call; Making multiple instances of the monitor module and combined with the use of monitored record to revolve deadlocks; Allowing exception handler to abandon computation to continue the execution of current procedure.

Compared with Hoare’s monitors, the waiter must reevaluate the situation each time it resumes. However, it avoids extra process switches and no constraints at all on when the waiting process must run after a NOTIFY. Mesa added three rules to resume a waiting process: timeout, abort and broadcast.

On priority, instead of associating with each monitor the priority of the highest priority process which ever enters that monitor, Modula solves the problem in a way that interrupts are disabled on entry to M thus effectively giving the process the highest possible priority as well as supplying the monitor lock for M.

Finally, implementation details of Mesa/

4. Evaluation
There is a particular evaluation session of the performance. The author evaluates the cost of storage of a Mesa module and process, the execution time and calling and returning from a monitor entry procedure. Based on the results, the implementation meets the efficiency goals. Besides, the author also makes analysis in the separated session while introducing components of Mesa.

5. Confusions
What it means in “belong in an abstraction”.

Summary :
The paper talks mainly about how synchronization is achieved in Mesa using monitors. In addition, it also discusses about using condition variables in monitors, the semantics of wait and signal, and how I/O interrupts can be dealt with using monitors and condition variables. The paper provides basic performance statistics of the time taken for various operations in Mesa which use monitors for synchronization.

Problem :
The problem here is to implement a suitable mechanism for synchronization between threads of a process/ multiple processes. For concurrent programs that access shared data, mutual exclusion is necessary. To achieve this using monitors is the main focus of the paper.

Contributions :
1. Processes use forking, are lightweight and the cost of creation and destroying process is low. Also, the cost of storage for a process in Mesa is very reasonable.
2. Merging of synchronization using monitors into an object oriented programming environment makes it quite simpler.
3. Related procedures and the global data is grouped into a module. Monitor procedures can be entry procedures or internal procedures. Synchronization is achieved by allowing only a single process to execute in a monitor while the rest of the processes that call the entry procedure will have to wait. Entry procedures enforce synchronization by using monitor locks.
4. Semantics of wait and signal is different from that of Hoare semantics. The signal/notify is only a hint to a waiting process that it could resume. Before resuming, the waiting process has to recheck the condition and acquire the monitor lock. Makes the implementation simpler.
5. Alternatives to notify such as resuming after a timeout, abort or a broadcast to wake up all processes waiting on the condition to resume instead of a waking up a single process.
6. Naked notify is used by I/O devices to notify a condition variable that wakes up a suitable interrupt handler.
7. Priority of the highest priority process entering the monitor is associated with each monitor so that priority scheduling is not affected.
8. Implemented by using four different queues - ready queue, monitor lock queue, condition variable queue and a fault queue. A process is moved to the appropriate queue based on the occurrence of events.

Evaluation :
The storage overhead of various constructs has been measured and it is observed that changing a module to a monitor required an addition of 2 bytes of data and 2 bytes of code.
The size of the activation record of an entry procedure is the same as that of normal procedure. The time taken for some of the major operations has been measured. Process switch takes 60 instructions, 15 instructions for a wait, 6 instructions for a notify and 1100 for a fork/join. There is no relative comparison with any existing synchronization mechanisms however.

Confusion :
The issues with naked notifications. Why are semaphores more widely used than monitor constructs for synchronization?

Summary
This paper describes the abstraction used to implement concurrency in a programming language called Mesa. In Mesa, concurrency is handled in Monitors which are responsible for synchronization, the shared data, and the code which performs the access. A monitor is simply an instance of a module, which is a set of procedures and data used to implement a data abstraction. Additionally, the paper describes Mesa’s semantics when waking up from conditional variables, which only provide a hint to the signaled process that the condition has changed.
Problem
The problem facing the authors was to implement a safe vehicle for concurrency control in the programming language Mesa. Mesa already had a defined organization system in modules and the concurrency mechanism for synchronization must fit into this pre-defined structure. Due to the simplicity of implementation, the Monitor schema of synchronization was chosen over message passing. Monitors also provided a level of modularity that shared memory doesn’t offer.
Contributions
The authors defined a monitor to be an instance of a module in the Mesa programming language. In a monitor, there are three types of procedures: entry, internal, and external. Entry is an entry procedure into a monitor and can be called from anywhere. Internal processes are private to the monitor and can only be called from inside the monitor. External procedures can be called from outside the monitor, but they don’t access any shared data inside the monitor. Another main contribution was the definition of how nested procedure calls are handled. In Mesa, when a monitor calls another procedure outside the monitor, the lock is not released. This could cause a wait if the next procedure is in a monitor. In Mesa, a code was also shared between objects that needed a shared monitor module, but operate on different data, such as files. A new type constructor called a monitored record is available, which allow the programmer to specify how to access the specific monitored object. This can be done via a parameter to a procedure or a global variable. Finally, the authors introduced Mesa’s semantics for waking up from a wait on a condition variable. When waking up from a wait on a conditional variable, the signal is treated as a hint that the condition might have changed, but not that it necessarily did. The waking process must re-check the condition to be allowed to continue. This is because another process could have woken before the current one and changed the condition.
Evaluation
Some basic evaluation of the monitor code was presented, showing that the additional code adds minimal storage to the existing codebase. With the exception of Fork/Join, the latency added to the Mesa programming language because of monitors is also minimal. They found that Fork/Join being inefficient was too much of a problem, because detached processes (which don’t join with the parent process) aren’t too popular in their system. Overall, the performance of monitors was favorable.
Confusions
What is a wakeup-waiting switch and how is it used to solve the race condition introduced by the naked notify?

1. Summary
The design decisions and implementation of monitors and processes as used in the Pilot operating system are detailed. These decisions are unique to the Mesa language and constructed for local concurrent programming use.

2. Problem
Monitors had been invented and had seen some use in previous research environments. However, the authors of the paper found that these previous efforts were insufficient, and implementing monitors into a real OS required solutions which did not exist. One of the most important goals was that processes should be able to be dynamically created. Additionally, the precise mechanics of scheduling waits on condition variables had not been established, and the problem of waiting within a nested monitor call had not been suitably solved.

3. Contributions
Processes can be dynamically created and destroyed, and can be referenced essentially as pointers. Processes are invoked very similarly to procedures, and inherit the same parameter passing mechanisms. They can also be detached from the parent to allow for independent, untied processes. These processes can then interact concurrently with different data structures, which lead to the monitors that are the main contribution of the paper.

The monitor module has three distinct types of procedures. Entry procedures are called from outside the monitor, while internal procedures are only used internally. These procedures operate with the monitor lock held, while external procedures do not. The mechanics of lock releases are particularly interesting: waits in an internal procedure must release the lock, while waits that occur outside the monitor must hold the lock. This is to maintain the invariant that whenever a procedure enters the monitor, a property of the data can be assumed. This means the monitor must establish the invariant before returning from an entry procedure or calling a wait. When calling an outside block, there is no way to know whether a wait will occur. To avoid having to establish the invariant before each outside call, waits that occur will simply continue to hold the lock.

The semantics of condition variable waits are another main contribution of the paper. When a process affects a condition variable, it simply notifies the condition variable. This is only regarded as a hint - the woken up process much check conditions to ensure it should enter. This relaxed approach simplifies verification globally, and allows a single condition variable to signal a number of related conditions - each process just checks its own restrictions when notified.

4. Evaluation
The authors provide show that monitors have a small space overhead - only a few additonial bytes for code and condition variables. Calling and returning takes about 70 percent longer than ordinary procedures, while fork and return takes about 38 times longer than a procedure call. They feel they have achieved their original goals, with the exception of fork/join. Several example applications which use processes and monitors heavily are detailed. They find that lack of mutual exclusion when handling interrupts, and the interaction of Mesa signals with processes and monitors are especially difficult. However, the authors use monitors and processes as the only concurrency mechanism on their personal computer, showing the implementations can achieve real-world use.

5. Confusion
Are monitors really that much better than using locks and condition variables on a finer scale? They mention several issues that the programmer must handle (in addition to using monitors). With the extra overhead, it seems like they don't accomplish enough.

1. Summary
This experience paper talks about the integration of processes and monitors to Mesa for concurrent programming. Despite extensive research, a number of practical questions pertaining to Monitors were unresolved such as the meaning of condition variable WAIT within a nested monitor call. This project provides concrete semantics for such questions and validates their choices and system by building complex concurrent programs on it.. The implementation is split across hardware, runtime system and compiler.

2. Problem
The goals of this sytem are: (1) Enable local concurrency, (2) Enable global resource sharing across processes and (3) Provide light-weight notification over interrupts. Message passing paradigm can also achieve these goals, but was rejected due to dissimilarity with their existing infrastructure. Within the shared memory paradigm, monitors are chosen because of they are flexible, robust and naturally enforce structure on parallel programs.

3. Contributions
Processes are integrated as modules into Mesa. Processes can be forked at any time and are represented through variables which can be shared. Any procedure can be forked as the root procedure of a new process, however it must contain an exception handler. Monitor is an encapsulation of (1) shared data, (2) synchronization around this data and (3) code that will access this data. At any time, only one process can be ‘inside’ the monitor. Other processes will wait to get access. Similarly, processes can also WAIT or NOTIFY other processes on conditions. The monitor provides a certain invariant which must be maintained before a process leaves a monitor on exit/wait. This invariant can be assumed when the process enters the monitor. To simplify the verification of monitors, MESA proposes that the process should hold onto the lock while calling an external procedure. Deadlocks are possible with monitors whenever there is a cyclic dependence. Mesa suggests that deadlocks can be avoided through good coding practices only. When a monitor routine raises an exception, Mesa will provide control to the same routine to ensure that the monitor invariant is re-established before the process is destroyed. For condition variables, Hoare’s semantics requires the notified process to run immediately. This may require multiple context switches and a robust signalling mechanism. Mesa’s semantics imply that a NOTIFY is merely a hint that the state of the world has changed, the resumed process has to re-evaluate the condition before progressing. This enables new ways of resuming such as timeout, abort etc. Mesa also suggests solutions to avoid monitor scheduling from inverting assigned priorities.


4. Evaluation Mesa’s implementation is split across hardware, runtime-system and compiler. Most frequent operations such as monitor lock/release are implemented in hardware. Less frequent tasks such as FORK/JOIN are implemented in runtime. The compiler provides type- and syntax- checking. Diversely concurrent applications are implemented on top of this system to validate this system.

5. Confusions
How did Mesa achieve its second objective - enable global resource sharing across processes?

1. summary
The current paper discusses the design of monitor based concurrent programming methods for Pilot Operating System. These methods can be used for local concurrent programming, global resource sharing and as a means to replace interrupts.

2. Problem
The paper addresses several issues that the authors faced when working with monitors and it’s integration with the semantics of Mesa. Some of them are the programming semantics for a module based programming structure, ability to dynamically create processes and monitors, WAIT calls and related issues of deadlocking and race conditions, exception handling, priority scheduling and interface with devices.

3. Contributions
A process is treated as a procedure and it carries the same semantics as a normal function call. It can be assigned to a variable or passed as a parameter. They can either be waited on by the root procedure or can be detached and executed independently.
Monitors are implemented as a set of procedures and global data. A monitor consists of entry procedures which provide external interface and exclusive access operations to shared memory, internal procedures called locally by procedures inside the monitor and external procedures that do not access shared memory.
Monitors allow fine grained locking to a collection of shared objects. The semantics allow a process to acquire lock on the resource set as a whole or different locks on individual objects. Condition variables are implemented through notifications. A process can notify another process of a condition it is waiting on, without enforcing any constraints on execution order. Devices use naked notify to wake up a process on a pre-determined condition variable. This is required since the device cannot wait on a monitor lock.

4. Evaluation
The method is split and implemented in the Mesa compiler, the runtime package and in the operating system. The space and time overhead of the interfaces is evaluated against basic Mesa constructs. The overhead of adding process, monitor and condition variable amounts to about adds about 16 bytes of additional storage. The cost of procedure call increased from 3 bytes to 13 bytes for a fork/join call. On the other hand, monitor entry is 70% more time consuming than a normal call and return. The overhead of fork/join call is highest with 38 times more than that of a procedure call.

5. Confusion
I did not clearly understand the mechanisms of monitored record. Can you please explain this.
And a more general question, monitors don’t seem to be primitive synchronization operations like semaphores and mutexes. Does this really limit it’s usability for coding general applications?

Experience with Processes and Monitors in Mesa.

Summary:
In this paper, the authors describe a new approach with the use of monitors for concurrent programming in Mesa. The paper discusses the concept of process and monitors in Pilot (an operating system). The paper also talks about how condition variables are used in the proposed system. The authors also talk about the implementation and the way in which processes and monitors are used in Mesa programs in Pilot.

Problem:
The authors wanted to develop concurrent programming facilities for Pilot which would support local concurrent programming, global resource sharing and an alternate to interrupts. As a solution, monitors were selected for developing the framework of concurrent programming. The choice of monitors leads to the problem of defining the program structure, creation of processes and monitors, handling exceptions, I/O and scheduling.

Contribution:
The facilities for concurrent programming was designed as part of Mesa as Pilot was based on Mesa. The authors choose to use shared memory for IPC instead of message passing so there was no problem of integration. Processes were created by using a special procedure call. Also the return value of the procedure could be retrieved later so that time is not spent waiting. This scheme makes process synonymous with the value in language. The use of detach process helps to create process which need not return a value to the creating process. The exception handling mechanism is done in such a way that it flows down the hierarchy such that the parent process can handle if the child process has not handled the exception. Monitors are used for synchronization, shared data and to perform accesses. Protection is enforced by ensuring that only entry procedures can access data in monitors and internal procedures can be called only from monitors. The monitor module is used to package a collection of data and protect it from external access. Replication of monitors for multiple objects is achieved using monitored record. The UNWIND provides an easy way to clean up exceptions. The use of condition variables is established by using a NOTIFY which is a hint to a waiting process. By increasing a process’ priority to that of the monitor when entering a monitor starvation is avoided.

Evaluation:
The authors tabulate the performance of their implementation in terms of data and program storage. They also measure the time taken for execution in terms of tick on a MIP machine. The authors do not provide conclusive results by comparing the system with other system’s performance. Also the paper discusses more about the Mesa programs that use monitors and process. But their performance is also not compared with any other existing system.

Confused about:
I could not completely understand the naked NOTIFY.