CS 736 Reviews - Spring 2017

1. Summary
This paper is about the use of Monitors for concurrency in MESA programming language. The paper explores the different issues in integrating concurrency in into programming language like exception handling, WAIT implementation, priority scheduling, etc.
2. Problem
Monitors are being used for concurrency in programming languages, but the problems and semantics haven’t been addressed clearly. The problems include the meaning of WAIT, priority scheduling, handling of timeouts, aborts, exceptions, monitoring large number of small objects. Authors have addressed these problems by integrating Monitor based concurrency in Mesa programming language.
3. Contributions
Authors have used Pilot Operating System for evaluating the benefits of Concurrency in Mesa. The most notable contributions include Program Structure, creating processes, creating monitors, WAIT in nested monitor call, Exceptions, Scheduling policies, IO interactions with Monitors. Authors have explained the Process structure used in Mesa Programming language. The Monitor is implemented as a module in Mesa. Authors have discussed the Deadlock possibilities in Concurrent environment and why Mesa prefers to rely on programmers to tackle deadlock scenarios. Authors have created a new constructor in Mesa called Monitored Record that encapsulates Monitor lock to serialize the access to shared data objects. Mesa allows time-out for ‘wait’ call. Mesa uses notify to wake up waiting processes. The waiting processes need to re-acquire monitor lock.
4. Evaluation
The authors have compared the space and time overhead of Mesa Monitor on Pilot Operating System. The authors feel that Mesa implementation has met sufficient benchmark expectations. The function calls bear few extra ticks than ordinary procedures. The fork Join seems to be taking highest overhead by taking 1100 extra ticks (38x than without mesa monitors). The calling and returning from monitor entry procedure is also taking 70% more time than ordinary procedures.
5. Confusion
The comparison of Mesa and Java could be useful.

Summary:
This paper explains the design and development of monitors within Mesa. It discusses various approaches to implement monitors and provides a real-world implementation of monitors on large-scale system and many practical issues associated with monitors that are not clearly resolved in the contemporary work on monitors.

Problem:

At the time the authors wrote the paper despite dynamic nature of operating system and user applications several problems in different phases of concurrency such as fixed number of processes and monitors, semantics of nested monitor calls, definition of WAIT in nested call, exception handling and scheduling and scheduling of priority inverted processes were open. The authors address these issues by providing flexible and programmable synchronization facilities and integrating them in the Mesa language.

Contribution:
The authors provide insights into the problems which were not handled by literature in monitors at that time. They explain how the creation of processes happens concurrently with caller and the implications it has. Monitors and Monitor modules are defined and the correctness argument for processes using Monitors is provided. The authors describe alternative ways in which a process can be resumed – timeout, abort, broadcast. They also introduces the concept of ‘naked notify while communicating between devices such as I/O. The authors describe how exception handing can be done using aborts and timeouts. They provide a solution to the the priority inversion problem by increasing the priority of the process holding the monitor to the highest priority of the waiting processes.

Evaluation:
The implementation of process and monitors is done across the Mesa compiler, runtime package, and the underlying machine. The authors then provide a performance analysis and the storage overhead associated with various constructs of Mesa .They find that with the exception of Fork/Join the overheads associated with other constructs even though high are still within reasonable limits. Their justification that this is not a major issue as Fork/Join are less frequently used is convincing considering the other functionalities introduced. The authors also tested the monitors on three other systems including the Pilot operating system, a distributed calendar system, and a internetwork forwarder which gives a better understanding of and analysis how the primitives introduced by them affect the development and performance of these applications.

Confusions:
The working of naked-notify was not very clear.

1. Summary
This paper describes an implementation of monitors in the Mesa programming language at Xerox PARC. Monitors are tightly integrated with the Mesa language, encouraging programmers to decompose programs into processes that execute independently and signal each other whenever necessary.

2. Problem
Prior to this paper, there were many different implementations and interfaces of monitors as a tool to synchronize processes. Some implementations assumed a fixed number of processes or monitors. Others did not behave correctly when performing a WAIT in a monitor call. In some implementations, processes experienced priority inversion if there were three processes with different priorities and the highest priority process was waiting on a monitor held by the lowest priority process.

3. Contributions
The system allows the programmer to fork processes easily and create a monitor wherever necessary. A Mesa-style monitor ensures that only one process can execute a piece of code at a time, and other processes waiting for the monitor are notified when the monitor becomes available. Monitors themselves are a low-level concurrency primitive; the programmer must make sure that any necessary invariants hold when a monitor is released, and the programmer must also make sure that processes waiting for a monitor do not continue to execute. Even though deadlock is possible, the system provides tools to help programmers locate deadlock. A process waiting for a monitor is not guaranteed to execute as soon as the monitor becomes available, but starvation is unlikely in a well-designed system. The authors solve the priority inversion problem by increasing the priority of the process holding the monitor to the highest priority of the waiting processes.

4. Evaluation
There are very few numeric evaluations. The authors report the storage costs of monitor operations compared to other Mesa constructs. Monitors have a small space overhead over ordinary Mesa modules, and WAIT and NOTIFY use a small number of bytes of code. In terms of performance, a monitor call and return have a small overhead over an ordinary call and return, but FORK and JOIN have a much larger overhead. There are no higher-level benchmarks.

5. Confusion
I did not understand the need for naked NOTIFY. Why are input/output devices unable to use monitors, the way processes do?

1. Summary
This paper introduces Mesa as a concurrent programming language and the detailed implementations in Mesa, such as processes, monitors and condition variables that support this system. This paper discusses some common problems related to monitor design, process synchronization, and shows their solution for these problems.
2. Problems
The main problem this paper tries to solve is how to build real world concurrency system with many processes executing, synchronizing and communicating with each other. There is some existing research about using monitor as a way of resource sharing and synchronization, however, during the implementation of monitor, people at Xerox found a lot of uncovered problems such as unclear semantic of wait and process scheduling. They tried to solve these problems and proposed Mesa and successfully applied it to Pilot.
3. Contributions
The main contribution of this paper is the implementation of monitor in Mesa which is a real-world system. Processes in Mesa are treated just like other values, they can be passed as argument, assign a value, and there is also strong type checking and exception handling for processes. Monitor, is an object comprised of shared data, synchronization method, and methods to access the data. Three procedures, entry, internal and external, the combination of these three guarantees mutual exclusive to shared data in monitor. This modular design helps to make the multi-processes design to be clean. Instead of the previous signal mechanism, Mesa uses NOTIFY and has timeout, abort and broadcast as three alternative ways to resume waiting process. Some other issues like the implementation of condition variable, monitor deadlock, and priority of processes is also discussed in this paper.
4. Evaluation
For performance analysis, implementing such a system first requires some space overhead, like a module requires an additional 8 bytes of data and 2 bytes of code, and changing module to a monitor requires 2 bytes of code and data. Second, for running time, this paper tests some process operations, like procedure call and return is about 70 percent more than traditional ones, fork join is about 38 times of a procedure call. The real applications also work as an evaluation. Three system related to Mesa, which are Pilot, Violet and Gateway, are all examined in this paper.
5. Confusion
(1) I don’t understand what is the connection between multi-processes and programming languages like Mesa. And some say it even has some relationship with Java? Or java is influenced by Mesa? I cannot see what is the relationship between these two.

1. Summary

This paper describes the experience of the authors is designing concurrency support for Pilot OS through processes and monitors. This is done by providing concurrency in mesa programming language which was the language of Pilot OS.

2. Problem

Monitors had been already been around at the time of this paper but there were a bunch of issues that had not been addressed by them. The existing Monitor systems did not support dynamic process creation and destruction. They were only good for a fixed number of processes defined at compile time. Similarly the issues of nested wait calls, priority scheduling, and exception handling were also poorly addressed by existing implementations of Monitors.

3. Contributions

The authors implement Monitors as a module in the Mesa Programming language. A monitor consists of an entry point and a set of public and private procedures. Synchronization is achieved by associating a lock with the monitor procedures such that at most one process could be executing a given procedure at a time. Secondly, the authors have implemented a simpler version of conditioned variables compared to Hoare. In this model, the notify function only acts as a hint for the waiting process and does not provide any scheduling guarentees. The waiting process has to recheck the invariant itself after waking up. The authors also provide cleaner semantics for exception handling through UNWIND. It allows cleanup when the exception occurs while the process was holding the lock and there was no exception handler in the callee procedure.

4. Evaluation

The authors have implemented Mesa Monitors by modifying the mesa compiler, the runtime package and the hardware. They measure the storage overhead for monitors and condition variables which turns out to be not significant. The authors measure the cpu performance of wait , notify, fork and join and find that wait and notify meet the efficiency goals. However, fork and join are much slower due to software implementations.

5. Confusion

This paper seems to be quite influential. A broader discussion of its background and influence would be great.

Summary

The paper describes how “monitors” were integrated into the Mesa language to achieve concurrency while also taking into account the various problems with earlier implementations of monitors.

Problem

Previous implementations of monitors had issues like dynamic process creation and destructions being restrictive, lack of exception handling, ambiguity in nested monitor calls, lack of a good scheduling mechanism and others. These seemed to be a major hurdle to integrate monitors with MESA to be used in the PILOT OS.

Contribution

Unlike previous implementations the monitor is implemented with explicit policies such as WAIT, priority scheduling, exception handling.

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.

Evaluation

Apart from showing that the various overheads caused by the new implementation of monitors don't cause any real increase in space requirements or execution time the paper has not done any other extensive evaluation.

Confusion

Can the use of naked NOTIFY

Summary:
The paper starts with enumerating benefits/usage of concurrency, followed by listing issues with the then approaches to support concurrency, and then it outlines methods to integrate processes and monitors in Mesa programming language, in order to provide synchronization. It discusses various approaches to implement monitors and provides a real-world implementation of monitors on large-scale system. In the process of doing so, it also delineates semantics of NOTIFY and WAIT calls, and treats processes as a special procedure call.

Problem:
In late ‘70s, facilities proposed or available to facilitate concurrency were restrictive in nature such as one of them required number of processes to be fixed at compile time, another required number of monitors to be fixed. These proposals/implementations were not reasonable considering the dynamic nature of operating system and user applications. Synchronization facilities at that time also had issues like inadequate in handling exception, lack of agreement for precise semantics of waiting on condition variables, WAIT in nested monitor calls, inadequate I/O handling by concurrency frameworks.

Contributions:
1. Differentiate procedure calls to handle wait – External (opaque to other procedures, does not lock monitors automatically), Internal (transparent to external procedures, believes lock is held), and Entry (opaque to external procedures only, requires lock and does automatic locking).
2. Provides improved semantics – More convenient to use and less expensive to implement. Removes many stringent requirements for resource demands. Allows time-out for wait() call. Introduces a new notify() (called naked notify) which does not require the lock.
3. Handles exceptions better than then-available synchronization facilities. Allows a procedure to abort the computations done by procedures called by it, generates UNWIND exception in such as case which allows procedures to do any cleanup necessary before activation is destroyed.
4. Introduces Monitored Record to help in serializing access to shared data objects. Monitored record is different than ordinary record in the sense that it includes monitor lock and is intended to be used as protected data of the monitor.
5. Proposes solutions for deadlocks in various cases, such as partial ordering on resources in case of cyclic calls, breaking monitor (M) into another monitor (M’) and module (module-0) in case of infinite waiting due to dependency on caller.
6. Solves the problem of priority inversion by assigning monitor the priority of highest process whichever enters that monitor. Temporarily increases the priority of process entering the monitor to monitor’s priority which in turn is highest priority.

Evaluation:
Authors measured the space overhead and performance overhead of monitors on Pilot operating system. They found these overheads to be within reasonable limits (only few additional bytes in terms of storage, and 70% overhead in performance for calling/returning, 100% performance overhead for process switch), with the exception of Fork and Join case (Fork/Join call takes 38 times than normal call). These evaluations however seem to be limited in scope, considering only small variety of applications (OS, distributed calendar, N/W forwarding) were assessed. Also, paper can be structured better for easier read.

Confusion:
How does monitored record work in order to facilitate shared data objects?

1. Summary
Lampson and Redell discuss their experience with implementing mutual exclusion primitives, in this case monitors. Their goal was to design Pilot, their OS, with these primitives as a first class objective. They review their design decisions and some of the implications they have in applications of that era. Importantly, they designed this system for a single user machine.

2. Problem
Applications working as the orchestration of processes enables higher performance. To achieve this, mutual exclusion must be enforced as to create this synchronization. The limited scope of prior work led to some frustration as they encountered issues not previously discussed in published work. How can you effectively implement monitors with limited overhead in an operating system designed to service generic applications?

3. Contribution
The major contribution here is the discussion and insight into their design decisions as they were designing monitors as a part of Pilot. The first major design decision is how monitors should interact with processes. This fostered deeper discussion about how should these work in reality. Specifically, they talk about the programming semantics, how should scheduling occur and the ramifications of adding monitors, nested calling, exceptions and I/O. This was accomplished by incorporating monitors into Mesa as a first-class value, consequently modifying the Mesa compiler, runtime package and the underlying machine.

The discussion about how condition variables should work really stood out to me as we continue to follow the pattern today. They explicitly chose to forgo a forced dependency with the scheduler and thus use the pattern of while instead of if. I assume this is where the notion of broadcast vs notify-one came about as notification methods.

I see parallels with their methodology with similar to how RPC thought about their problem a few years later. They specifically identify meaningful constructs they need to deal with such as nested calling and exception handling as well as problems around deadlocking. Scheduling was interesting as you see a lot of those ideas carry on today and other research around that time evaluated methods for doing it a little smarter like priority inheritance and priority ceiling protocols to avoid priority inversion.

4. Evaluation
Overall, overhead numbers for memory usage were presented and seem good. The performance of fork+join was rather underwhelming, but they attribute it to the software implementation rather. I’m not entirely convinced and would have them to have torn apart those numbers as nicely as they presented the memory overhead. Outside of that, most of the evaluation discussed how applications were able to take advantage of the monitors.

5. Confusion
I am not entirely sure why they decided to define a tick arbitrarily though, while not important, just kind of a weird moment.

Summary
The paper talks about the design, development and evaluation of processes and monitors in the Mesa language with the objective of facilitating reliable concurrent programming.

Problem
The authors listed several problems in existing monitor implementations in Mesa. It had large scale drawbacks for handling concurrent applications that varied in size and functionality because of issues such as nested monitor calls, handling WAIT calls, interaction of priority with the locks, exception handling and large number of synchronisation modules for objects.

Contributions
The design proposed allows asynchronous creation and execution of processes from their callers. It considers processes as procedures, as parameters can be passed to processes and the results of processes can be retrieved. This facilitates dynamic process creation and solving of synchronization problems by using monitors. Authors integrated a monitor into the basic unit of Mesa code structure, the module. There are three types procedures in a module : external, entry, and private. External procedures can be called from other modules and manipulate the module's data in a thread-safe way, so they do not obtain the lock of the module's monitor. Entry procedures can also be called from other modules, but they obtain the monitor lock. Private methods can only be called from other procedures of the module and hold the monitor lock.
The paper also describes a new design for condition variables. This new design treats Notify on a condition variable as a hint to a blocked process to resume execution at some future time. This helps many applications as they now do not need to determine if the exact waiting condition has been established. Interaction with I/O devices is achieved through atomic read/write operations and the “Naked Notify” mechanism that allows a device to interact with its interrupt handler without acquiring a monitor lock. Deadlocks are possible when monitors are incorrectly programmed, however, Mesa provides an environment which allows easy deadlock avoidance.

Evaluations
The authors evaluated space overhead of the monitor implementation and time overhead of basic operations like process switch, notify, fork/join and wait. The evaluation over memory suggest that the amount of extra memory needed in each module and procedure, and that needed to run processes and monitors is less than 16 bytes. Evaluation over time overhead suggest that all operations take less than the time of 60 instructions, except for Fork/Join. This is caused by the implementation in software rather than in hardware. Authors also talk about their experience while designing certain applications - Pilot (a general purpose operating system), violet (a distributed calendar system) and gateway (an internetwork forwarder) - using the refined constructs of processes and monitors in Mesa.

Confusions
The idea of monitored records is not quite clear and I also did not understand the syntax used.

Summary
The paper is about authors' experiences with mesa, in providing programming facilities for concurrency and processes in pilos OS. Authors dicussus many issues related to concurrency such as timeout, aborts, exceptions etc and provide solution for them.

Problem
Monitors used in real systems have various problems like the defining of WAIT; priority scheduling; handling of timeouts, aborts, exceptions etc. Authors try to addresses these problems by integrating processes and concurrent programming in Mesa, providing interrupts alternative, global resource sharing and local concurrency.

Contribution
The most important contributions are the issues that authors addressed; Program sturcture: organizing programs as modules, Fixed processes: allowing varying number of processed to be created, Creating Monitors dynamically, Wait in nested monitor call, exceptions, scheduling and IO. Authors handle the nest monitor calls that avoids Hoare semantics by not transferring control across processes, but by putting the waiting process to ready state from blocked state. Authors state that this is not ultimate solution to deadlocks and application will have to handle deadlock by themselves. Monitors are integrated into programming language as kind of a module and a certain function can be locked by placing keywords (like synchronized in java). They also provided exception handling that would automatically release lock before handling the exception; this enabled proper unwind mechanisms for nested monitor calls. Authors also discuss about IO interrupts through naked NOTIFY and fine-grained locking.

Evaluation
Authors provide very less details regarding the evaluation of their implementation. The performance is expected from the intrinsic parallelism that Misa enabled. They talk about storage overheads, time taken for different constructs, cost of FORK, JOIN and state that their expectations of efficiencies have been met with the exception of FORK and JOIN.

Confusion / Question
For sure, this work has left its impact on programming languages like java, what other recent changes have been made to programming languages to provide synchronization between concurrent tasks ?

1) Summary

The recent (at the time of the paper) invention of monitors, primarily by Tony Hoare, leads the authors to explore its use in real systems. In their design of the Mesa programming language and its applications, they come across a number of issues that nobody had ever considered before. They describe some of the design choices they made in Mesa.

2) Problem

In 1974, Tony Hoare proposed the idea of a monitor, which is essentially a data structure with a lock and condition variables. This idea has proved to be a useful notion and is the primary synchronization mechanism in Java.

However, the authors, writing only a few years after the invention of monitors, describe some of their experiences in adapting monitors for use in real systems. They describe their implementation of monitors for the Mesa programming language, which they subsequently use to develop several systems, including an operating system and a distributed application. In particular, they describe practical challenges surrounding the semantics of WAIT/NOTIFY, nested monitors, exception handling, and I/O, among other problems.

3) Contributions

The primary contribution of this paper is a set of design choices that prompted discussion about the best semantics for monitors. Their final choice of implementation for Mesa is very similar to what Java currently implements.

The authors propose that notify should wake all waiting threads, and they propose the now popular `while not : wait` paradigm. They also explore the issue of nested monitors, exception handling, and whether I/O should allow devices to wait on a monitor. While all of the issues mentioned in their paper are still largely open questions, the solutions proposed in this paper are widely used today in modern programming languages and synchronization libraries.

The exploration of these issues in the many different contexts by the authors allowed them to gear their discussion towards general systems building design points. For example, implementing an OS or a distributed system requires the ability to handle devices or interrupts in a coherent, ergonomic, and efficient way.

4) Evaluation

This paper is a classic case of applying theory to systems. The original formulations of monitors largely ignored issues of practical importance to real-world program in the interest of producing an elegant synchronization primitive. The authors of this paper, on the other hand, are focused more on practical usage in system building. They identify many important issues in the use of monitors, many of which still generate a great deal of discussion.

The authors' proposed solutions have inspired many similar implementations today in languages such as Java. Their description of choices in each section explains what alternatives they had and how they made their choices. However, the authors do tend to include a lot of implementation details that can drown out their main messages. For example, they describe specific programming constructs in many places. This detracts from the main point of their paper, which is related more conceptually to the behavior and use of monitors.

Also, in the experimental evaluation section, the authors give the space and time usage of their implementation in Mesa. However, this evaluation section is not very useful because it contains no reference of comparison. Is the performance good or bad? Could it be better?

5) Confusion

I did not understand why the authors spend a whole section describing processes. Are they simply describing their FORK/JOIN mechanism (which sounds very similar to go's go-routines)?

Summary
The paper discusses the various issues related to the practical implementation of monitors and condition variables for describing concurrency. They have addressed most of these problems by the facilities present for concurrent programming in Mesa language using procedures and modules of the Mesa language.

Problem
I. When monitors are used in real systems of any size, a number of problems arise like: 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, interaction with process creation and destruction, monitoring large numbers of small objects.
II. Advent of things like server machines and networking introduced applications that are heavy users of concurrency, which lead to the need of the implementation of some synchronization technique.
III. Simple locking (e.g. Semaphores) - They have too little structuring discipline, with no guarantee that locks will be released on every code path. And it can not be integrated into a Mesa language construct.
IV. Ceding lock to waking process instantly leads to too many context switches.

Contribution
I. Monitor implementation in Mesa: Introduced monitor lock for process synchronization. In Mesa the simplest monitor is an instance of a module, which is the basic unit of global program structuring. Monitor module has three kind of procedures: entry, internal( private )and external. The first two are monitor procedures and are executed with the monitor lock held.
II. Condition Variables: Scheduling is done with the help of condition variables.
III. Nested Monitor Calls Handling: Standard monitors are broken into two parts: a monitor M' and module 0. Module 0 provides an abstraction to M' to access shared data and calls to other monitors are done from module 0 instead of from M'.
IV. Handles priorities in multiple waiting processes: Notifier just gives *hint* to waiting processes with no guarantees, waking process must recheck its condition and user can implement priority policy here instead of just waking the process which is front of the monitor queue. It also helps reduce number of context switches.
V. Monitored Records: It helps in handling multiple instances of something parallel with same monitor code.
VI. Exception Handling: Use of UNWIND mechanism. It make the an entry procedure to restore to invariant, release the lock, return with error, and then generate an exception instead of calling the handler from within the monitor without releasing the lock and if exception handler happens to call the monitor again, it can lead to deadlock.

Confusion

I know nothing about mesa :(

1. Summary
Introduction of monitors in real systems, irrespective of their size, can lead to problems in many aspects of the system like priority scheduling, handling timeouts, exceptions, aborts etc. The paper provides a solution by incorporating concurrent programming facilities in Mesa.

2. Problem
An operating system running on a personal computer should provide Local concurrent programming, global resource sharing and better alternative for interrupts at the least. In other terms, providing these facilities requires integration of concurrency into programming languages. Existing solutions had different problems in different phases of concurrency – fixed number of processes and monitors, definition of WAIT in nested call, exception handling and scheduling. The authors addressed these problems and integrated them into Mesa.

3. Contributions
The paper chronicles the experiences designers had with designing, building and using a system that leverages light-weight processes and monitors to satisfy its concurrency needs. The paper starts by identifying problems associated current systems providing concurrency and then justifying the choice of monitors. Process creation is simplified in Mesa, and they are treated like any other value (which seems similar to scala). The processes are made lightweight with low cost for creation, context switch and synchronization.
Monitor is an object which is tied to an invariant, which is comprised of shared data, synchronization mechanism and access modifier (similar to java). The design of modules has given rise to several aspects of java like Java synchronized objects. Monitor modules are similar to objects in java, which allowed grouping of related things into a module.
The paper also introduces a slightly different version of condition variable with ‘notify’ instead of ‘signal’. It also provides alternative ways in which a process can be resumed – timeout, abort, broadcast. The paper also introduces the concept of ‘naked notify’ while communicating between devices such as I/O. The paper discusses about deadlocks and provides ways to resolve them. The paper also explains about priority inversions, and priority boost as a solution to it.

4. Evaluation
The paper lays out the implementation of processes and monitors, which is split almost equally among the Mesa compiler, runtime package and underlying machine. The paper breaks down the storage overhead associated with various constructs of Mesa into data and code. The execution time is calculated in terms of ticks for different constructs. FORK and JOIN end up having high execution time. Otherwise, the authors say the results are satisfactory. The lack of performance of FORK+JOIN is justified by their software implementation. The paper also presents three impactful Mesa applications and the way in which of processes and monitors are used in them – Pilot, Violet and Gateway.

5. Confusion
1. It would be good to know why semaphores were ruled out completely, though the paper itself considers them good. They mention that semaphores exert too little structuring discipline. Can you please elaborate?
2. Can you please provide a comparison between Mesa, Java and Scala? Mesa seems to be a predecessor to both.

1. Summary
The paper discusses the experience of the authors in integrating support for concurrency through processes and monitors in the Mesa programming language.

2. Problem
Monitors were invented as a synchronization construct which provided a reliable framework for concurrent programming. However, at the time of development of the Pilot OS, the work on monitors was not comprehensive enough and there existed only one programming language (Pascal) with monitors integrated. Therefore, the authors had to come up with a solid solution for integrating threads and monitors into the Mesa programming language for reliable concurrent programming.

3. Contributions
The paper discusses several problems addressed in Mesa that were not handled by earlier work. Processes that behaved just like procedures could be invoked and be allowed to run concurrently with the calling procedure. The callee could later join with the caller or be destroyed if it was detached. The paper tries to remove the confusion regarding the meaning of WAIT in a monitor. If a caller has to wait in an entry procedure, it releases the lock. It is woken on a notify and needs to reacquire the lock when it enters the monitor. If WAIT is in one of the internal procedures, the lock is released. If a monitor calls an external procedure, the lock is not acquired or released because the lock is already held. The condition to proceed needs an extra evaluation. Notify is only a hint and the signaler can continue unlike the behavior described by Hoare. Priority scheduling is implemented by associating with each monitor the priority of the highest priority process which never enters a monitor. When a process enters a monitor, its priority is temporarily increased. When an exception occurs and a lock is being held, UNWIND allows cleanup when there is no exception handler for a procedure. Mesa automatically supplies the code to release the lock in such a case. Since devices cannot wait on a monitor lock, a Naked Notify causes an interrupt handler to be invoked without the acquisition of a lock.

4. Evaluation
The authors report the space consumed by data and code for various Mesa contructs, including those introduced to support concurrent programming. The cost of Mesa constructs in terms of time is also reported and FORK+JOIN is the most expensive due to their implementation in software. In addition to these numbers, it would be interesting to see the speedup obtained programs written in a concurrent manner making use of these constructs compared to their sequential versions.

5. Confusion
I did not quite understand monitored objects.

Summary
The paper shared the experience of exploring the usage of monitors with Mesa. The paper first talk about process management (such as creation, destruction etc.) and moved on the discussion on monitors. The paper discussed three kind of procedures: entry, internal (private) and external (non-monitor procedures). Later the paper also spend time to discuss issues with using monitors such as deadlock and abandoning a computation. Paper discussed the semantics of using condition variables and using a priority scheduling discipline for allocating the processor(s) to processes.

In the later sections, the paper discussed the implementation on the Mesa compiler, the runtime package and the underlying machine and described the applications of the Mesa programs.

Problem
While the use of monitors to support concurrency has been widely discussed in the literature, there are still many challenges when the authors were trying to incorporate it into real systems. As the paper wrote, the problems include “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 large number of small objects (Lampson et al., 1980).”

The authors made efforts to address these problems in their design and implementation of the compiler, the runtime package and the underlying system and shared the experience of the implantation in the paper.

Contribution
The paper identified and addressed challenges of incorporating monitors into real systems, with focus on program structure, creating processes, creating monitors, WAIT in a nested monitor call, handling exceptions, scheduling as well as Input-Output.

The paper discussed the design of three kinds of procedures in detail: entry, internal (private), and external (non-monitor procedures).

Mesa monitors are also designed to use a simple verification rule: the monitor invariant must be established just before a return from an entry procedure or a WAIT, and it may be assumed at the start of an entry procedure and just after a WAIT and use Timeout, Abort and Broadcast to resume a waiting process.

The authors implemented the monitors into a real system. The implementation of the processes and monitors consists the implementation of the Mesa compiler, the runtime package and the underlying machine.

Evaluation
The data storage overhead for a process is 10 bytes of resident storage. The process itself contains no extra code, but the code for the FORK and JOIN which create and delete it together occupy 13 byes, while a normal procedure calls and return takes 3 bytes. Calling and returning from a monitor entry procedure is 50 ticks, about 70 percent more than an ordinary call and return. The paper concluded the implementation has met their efficiency goals based on the performance figures, with possible exception of FORK and JOIN.

Confusion
1. How are modern programming languages (with respect to concurrency programming) influence by Mesa?

Summary:
Monitors are used to synchronize processes and protect shared data in concurrent programming. In this paper, the authors introduce their experience of implementing monitors for real large scale systems, including nested monitor calls, exception handling, interaction with priorities in scheduling and so on.
Problem:
Although monitors are widely studied in literature, there are still several critical problems unsolved to use monitor to implement real systems (Pilot OS in this paper), including semantics of nested monitor calls, WAIT definition in various ways, priority scheduling, exception handling and interaction with process creation and destroy.
Contributions:
The authors implement monitor modules in Mesa. They define the structure of monitor object to have three kinds of procedures: entry (callable from outside monitor), internal (callable only from inside monitor) and external procedure. The entry procedure is protected by a lock while the external procedure is not. Synchronization is guaranteed by having at most one process executing a monitor procedure at a time. Authors also choose a different notion of condition values from previous literature, and they use Notify as a hint to waiting processes for execution at some future time. They also implement timeout, abort and broadcast mechanisms for condition value. In order to avoid deadlocks caused by interaction with priorities in scheduling, they temporarily increases the process’s priority to monitor’s when the process enters monitor.
Using the monitor module they design in Mesa, the authors implement a general purpose OS, a distributed calendar system and an Internet forwarder.
Evaluation:
Authors report the storage overhead of components in their Mesa monitor implementation and that returning from a monitor entry procedure is 70% more than an ordinary call and return, in terms of timing. Although authors implement real systems with monitor, they do not report monitor’s performance for real applications.
Confusion:
Is monitor used is today’s OS? How is it better than just using semaphore?

Summary:
Many problems are associated with using monitors for describing concurrency. In this paper, the authors address these problems and resolve them for concurrent programming in Mesa.

Problem:
The use of monitors for concurrency has been much discussed in literature. But many problems arise that have not been dealt with when using them in real systems. There are issues with semantics of nested monitor calls, priority scheduling, handling of timeouts, aborts and other exception conditions, interaction with process creation and destruction, monitoring large number of small objects and various ways of defining the meaning of “wait”.

Contributions:
The authors successfully implement monitors using Mesa in Pilot, a new operating system. In their implementation, creation of a new process executes concurrently with its caller. There are three kinds of monitor procedures: entry, internal and external. Entry procedures can be called from outside and are protected by a lock. Internal procedure can only be called from monitor procedures. External procedures is called from outside the monitor and operates without locks. The authors redefine the semantics of condition variables. When one process establishes a condition for which the process is waiting, it notifies the corresponding condition variable. A “notify” is regarded as just a “hint” to a waiting process. The awakened process must verify that the condition of interest is true each time it is awoken. Since I/O devices can’t wait on monitor lock, naked notify is used that does not acquire lock. The priority inversion problem is solved by associating with each monitor the priority of the highest priority process which ever enters the monitor. Thus when a process enters a monitor, its priority is temporarily increased.

Evaluation:
The implementation of processes and monitors is split among the compiler, the runtime package and the hardware. The compiler generates appropriate code for syntactic constructs. The runtime package implements the process creation and destruction. Process scheduling and monitor entry/exit has been implemented in hardware. The authors report data storage cost and execution time overhead. The cost of calling and returning from a monitor entry procedure is about 70% more than an ordinary call and return. The authors also present high level details of three applications implemented using monitors and processes in Mesa.

Confusion:
I did not understand the concept of naked notify very well.

1. Summary
This paper looks at an implementation of monitors written in Mesa for the Pilot operating system.

2. Problem
The paper begins by listing the many problems they faced when trying to apply previous research to a real world implementation. The authors found that what they wanted to do with Mesa had not been covered without issues before. This included dynamic creation of monitors, creation of processes, and the implementation of WAIT inside a nested monitor call among other issues.

3. Contributions
The authors added to the Mesa language real world support for monitors. Monitors are used for synchronization, hold shared data, and the body of code which performs the accesses. The paper examines how you can fork off new processes to run concurrently with the old process. By using monitor procedures you can cause other asynchronous processes to wait while one process executes. Instead of immediately running when another process signals the variable that the a process is waiting on Mesa uses a NOTIFY instead. NOTIFY is like a hint to the process that it can resume at a future time. This means that the waiting process has to reevaluate the situation when it resumes but it allows for convenient scheduling of the process.

4. Evaluation
The implementation occurred across the Mesa compiler, runtime package, and the underlying machine. The paper broke down the amount of bytes for each part of their system such as WAIT and NOTIFY using 12 and 3 bytes respectively. Most of the papers implementations also seemed to be efficient with the exception of Fork/Join. The paper states that this should not be too much of a problem since they are used infrequently. The authors also applied the monitors to three systems including the Pilot operating system, a distributed calendar system, and a internetwork forwarder.

5. Confusion
After a brief search for the Mesa language it looks like it had an influence on Java. I am wondering if there are any of the implementations presented in this paper still in use today?

1. Summary
The authors discuss their experience with monitors in Mesa, the programming language behind Pilot - a OS for personal computer back then. To achieve their goals, they added support for creating processes and synchronization into Mesa.

2. Problem
Even though the use of monitors for concurrent systems had been much talked about in the literature, the problems related to actual implementation of Monitors such as - proper definition of WAIT, priority scheduling, handling of timeouts - were still not addressed. So when the authors started working on designing concurrency in Pilot, they considered the new design to allow local concurrent programming, global resource sharing and replacement of interrupts.

3. Contributions
The main contribution of the paper is not just the design of monitors but rather implementing them successfully into Mesa. This yielded a set of language features sufficiently powerful that they served as the only software concurrency mechanism on their personal computer (back in 1980s).
Mesa considers creation of processes as asynchronous procedure call and the new process executes concurrently with the caller process. The semantics of a process fit well with module feature provided by Mesa. It uses the ordering established by procedure calls to handle exceptions. Mesa provides monitors simply as an instance of a special module which has three kinds of procedures - entry, internal (private) and external(non-monitor procedure). All of these guarantee mutual exclusion for different processes. If WAIT happens to be in internal procedure, the lock is released but the lock is held when an external procedure is called. The application needs to handle deadlock in such a scenario. To address the problem of nested calls and also to define WAIT, the monitor also maintains an invariant which is always true except when there is a process executing in the monitor.

4. Evaluation
Overall, the paper does not talk about the evaluation in great detail. The time cost analysis for different operations is done and overall the authors conclude that the implementation met their efficiency goals except for FORK and JOIN. Finally, they also talk about three Mesa programs - an OS, a calendar system, an internetwork gateway - which use processes and monitors.

5. Confusion
Could you explain section 4.2 on Naked NOTIFY ? I do not know about the wakeup-waiting switch.

1. Summary
This paper discusses the experiences of the authors in integrating processes and monitors for enabling concurrent programming for the Pilot OS. It discusses the issues in integrating them such as timeouts / aborts, unwinds, priority scheduling for their multiprogramming environment, and how they resolved them.

2. Problem
There was a need for efficient synchronization primitives for concurrent programming for the application needs in the Pilot OS. The authors claimed that the existing methods and literature on the implementation of monitors and condition variables for synchronization had several shortcomings, such as the support of only a fixed number of processes and monitors, possibility of deadlocks in nested monitor calls, issues in exception handling, non-compliance with priority scheduling and handling I/O devices. They argued that these primitives did not solve several problems which were critical for their application needs.

3. Contributions
1. Monitor as a module - This allowed only certain procedures to be locked, and other procedures outside the critical section as public procedures. This definition also allowed the invariant semantic for release of locks, which allowed cleaner support for nested monitor calls.
2. Simpler NOTIFY semantics - By notifying waiting processes with only a hint and not providing any scheduling guarantees unlike Hoare monitors, this simplifies the implementation making it possible to implement priority scheduling in hardware itself. The key here is that hinting is not a problem because of the inexpensive process switching costs.
3. Exception handling - Exception handlers were to be defined for monitors, and lock release methods were added automatically, thus making the unwind mechanism work correctly for nested monitor calls
4. Fine-grained locks - The authors correctly identified that concurrency would be limited if only large locks were allowed, and thus introduced monitored records for fine-grained locking.

4. Evaluation
Processes and monitors were implemented by making changes across three layers -- the Mesa compiler, the runtime package and the hardware. Storage overheads for the monitor constructs and condition variables are given, and don’t seem to be much (although they might have been then?). CPU costs for monitor procedures are evaluated to show the efficiency of their constructs. It is found that WAIT, NOTIFY take less ticks than an entry procedure. However, FORK/JOIN takes significantly larger time as they are implemented in software.

5. Confusion
1. It would be nice if a brief overview could be provided of the existing synchronization primitives then. The paper does not do a very good job in explaining why Hoare monitors for example would be restrictive.
2. A take on the synchronization methods in modern languages (such as Go) and applications would also be nice.

1. summary
This paper describes integration of concurrent programming facilities to Mesa language for Pilot OS. Although the idea was not new, this paper solved problems in real systems which had not been attacked.

2. Problem
The authors aim at designing the concurrent programming facilities of Pilot, which is a new OS for PC. The programming language is Mesa. There does exist related work that integrates facilities into a language such as PL/1 and the monitors have been proposed. However, when monitors are used in real systems of any size, a number of problems arise which have not been adequately dealt with: 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 large numbers of small objects.

3. Contributions
The authors do not highlight its contribution. They deisgn Process, Monitor, and Conditional Variable for Mesa, but do not explicitly tell what challenges they are faced with and what is unique in their design. The only contribution for the design I can find is fitting these concepts in a certain language. Also they implement their design by hacking on the compiler, runtime package and OS.

4. Evaluation
The Mesa's concurrent programming facilities have nontrivial local costs, which need to be minized. The goal of the evaluation is to charaterize the costs of processes and monitors. Regarding the space, the overhead is small compared with the program and data. For the time consumption, the cost of calling and returning from a monitor entry procedure is 1.7x that of normal procedure calls. A process switch costs 2x the time of a normal procedure call. The minimal cost of a fork/join pair is about 38 times that of a procedure call. The implementation meet the efficiency goal.
5. Confusion
It is hard for me to recognize the difficulty of building the concurrent programming facilities on the Pilot using Mesa language with zero knowledge of Mesa. I do not know what distinguishes the authors' work from the POSIX thread programming. Are section 2 (Process), 3 (Moniter) and 4 (Conditional variable) the authors' work or built-in functions in Mesa?

1. summary
This paper describes integration of concurrent programming facilities to Mesa language for Pilot OS. Although the idea was not new, this paper solved problems in real systems which had not been attacked.

2. Problem
The authors aim at designing the concurrent programming facilities of Pilot, which is a new OS for PC. The programming language is Mesa. There does exist related work that integrates facilities into a language such as PL/1 and the monitors have been proposed. However, when monitors are used in real systems of any size, a number of problems arise which have not been adequately dealt with: 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 large numbers of small objects.

3. Contributions
The authors do not highlight its contribution. They deisgn Process, Monitor, and Conditional Variable for Mesa, but do not explicitly tell what challenges they are faced with and what is unique in their design. The only contribution for the design I can find is fitting these concepts in a certain language. Also they implement their design by hacking on the compiler, runtime package and OS.

4. Evaluation
The Mesa's concurrent programming facilities have nontrivial local costs, which need to be minized. The goal of the evaluation is to charaterize the costs of processes and monitors. Regarding the space, the overhead is small compared with the program and data. For the time consumption, the cost of calling and returning from a monitor entry procedure is 1.7x that of normal procedure calls. A process switch costs 2x the time of a normal procedure call. The minimal cost of a fork/join pair is about 38 times that of a procedure call. The implementation meet the efficiency goal.
5. Confusion
It is hard for me to recognize the difficulty of building the concurrent programming facilities on the Pilot using Mesa language with zero knowledge of Mesa. I do not know what distinguishes the authors' work from the POSIX thread programming. Are section 2 (Process), 3 (Moniter) and 4 (Conditional variable) the authors' work or built-in functions in Mesa?

1. summary
The paper introduced Mesa, a strongly typed, block structured programming language designed for concurrency control through monitors, specifically for local programming, global resource sharing and replacement of interrupts. The paper discussed many crital issues related to the design for monitors and also focus on the lightweight process as well as the synchronization.

2. Problem
They would like to build a large system with many programmers. The problem is to design a concurrency model suitable for that system, enabling resource sharing, mutual exclusion, and multiprocessing, which could be achived by the programming language, Mesa. They need to choose the way of inter-process communication (monitor, aka. shared memory or message passing). One hard part is synchronization, which is solved by preemptive scheduling of light-weight processes and monitors.

3. Contributions
a). Discuss various problems of implementing a light-weight-process and monitors design for a large system and this kind of experience makes sense to guide future work.
b). Specifically, program structure for monitors, dynamic process creation(fork prefix), deadlock when waiting for a call in nested monitor, how to handle exceptions.
c). The implementation of conditional variables.

4. Evaluation
THey provide evaluation for overhead of many primitives and implentation for three representative applications, pilot, Violet and Gateway. But there are not enough comparison result to show the performance compared to other model.

5. Confusion
a). I'm wondering the evolution of programming model from that point to more shared-data, like distributed shared memory.
b). Comparision with Java, Erlang, Golang's programming model.

1. Summary
This paper introduces the experience to implement process and monitor in an industry environment. The most important feature is how to implement monitor in a clean and bug-free way.

2. Problem
The time was 1979. The Xerox company built its own operating system (Pilot) and language (Mesa). The concept of monitor was invented several years before (1973 by Brinch Hansen), and later also proposed by Hoare (1978). The authors regarded monitor as a good way for process synchronization and encapsulation (encapsulate synchronization primitive: lock and condition variable). They started to implement monitor in Pilot with language Mesa, and encountered a series of problems that people who designed monitor in theory hardly noticed.

3. Contributions
The most important contribution should be the implementation of condition variable (Mesa semantics) in monitor. For the NOTIFY statement (e.g. pthread_cond_signal in C) of condition variable, previously Hoare proposed that (Hoare semantics), the process (e.g. A) which executes NOTIFY should transfer control to one process (e.g. B) which is waiting on the condition variable. After B finishes the execution of function, the control should be transferred back to A. The monitor lock is also implicitly transferred between processes when control flow is transferred. This may introduce several edge cases to consider in implementation. For example, (1).A NOTIFYs B, and B WAITs on another condition variable. Should B return monitor lock back to A or not? (2).How to implement broadcast or notify a "correct" waiting process (the problem introduced in paper 3.1) with Hoare semantics? The authors introduced hint to design condition variable. NOTIFY will only put a process from blocking state (condition variable queue) to runnable (ready queue). Most current OSs condition variable is implemented in this way. Mesa semantics is good in the sense to reduce the coupling between processes. One more test (while instead of if) overhead is negligible. In addition, the authors also pointed out WAIT/NOTIFY is not panacea for all synchronization problems. The Allocate/Free example in paper 3.1 can introduce deadlock (e.g. P1 calls Allocate(10) then waits, P2 calls Allocate(5) then waits, P3 calls free(ptr, 5) but notifies P1 instead of P2). Then they introduced broadcast to tackle the problem. This kind of problem can only be discovered when practitioners work on real software. The authors also talked about their way to implement process, exception handle in monitor and I/O interruption (naked NOTIFY).

4. Evaluation
The authors implemented monitor in Mesa language and used in their OS (Pilot), a distributed calendar application (Violet) and an internetwork forwarder (Gateway). The authors analyzed the space and time spent on each component of monitor, and compare them to regular function call. The result shows the efficiency of their monitor implementation except the obvious overhead for FORK and JOIN.

5. Confusion
(1).What is characteristics of Mesa language? The wikipedia says that "Mesa is an ALGOL-like language with strong support for modular programming." Is Mesa an early OOP language?

(2).Unix (1969) should be invented almost 10 years earlier than Pilot. How did Unix (in 1970s) support synchronization?

1. Summary
Monitors are objects that provide safe access to shared data in parallel applications. Although described in research literature, engineers at Xerox PARC describe issues they face in implementing them in a real system, highlighting nested calls, exception semantics, and scheduling issues.

2. Problem
Parallel programming requires some form of safety for coordinating access to shared data. Monitors are a high-level solution that encapsulates mutual exclusion, data storage, and access code in a single object. Their implementation includes the hardware, a runtime manager, and code interpreted by the compiler. Because monitors interact with many different parts of the system, they are tricky to implement well.

3. Contributions
The authors identify many areas of difficulty in implementing monitors in a real system: designing their structure, dealing with their creation, handling nested calls, scheduling semantics, exception behavior, and I/O devices. They also provide initial solutions to all of these problems.
They also identify 2 particularly annoying pieces of the development of their OS: a lack of mutual exclusion in interrupts and the interplay between concurrency and exceptions.
While the resulting OS is not (to my knowledge) still in use today, any OS designer must deal with similar issues. Being aware of the challenges with concurrency up front is a valuable contribution.

4. Evaluation
They provide the overhead of all of their data structures in bytes and the overhead of their concurrent calls in cycles of an abstract machine.
They describe at a high level the use of monitors in 3 different applications: their OS, a distributed calendar system, and a network forwarding program.
Beyond this, there is not a lot of concrete evaluation in this paper.

5. Confusion
The beginning of the paper compares message passing with a monitor-based system. It equates messages in the message passing scheme with processes in the monitor scheme. I don’t understand what they’re getting at with this comparison.