CS 736 Reviews - Spring 2016

Summary
This paper introduces the log-structured file system - all updates to both data and meta-data are written out in logs. It discusses a design to aid garbage collection and compaction, and provide fast look-ups /reads., and fast crash recovery.
Problem
With rapid evolutions in processor and main memory, disk latencies dominate the performance of i/o intensive programs. Due to mechanical limitations disk seeks are expensive and offset the gain from high write/read bandwidth. Contemporary file systems stored much of their meta-data (inode blocks) away from actual data blocks, requiring multiple seeks to update/create files. A second issue was that meta data updates were required to be synchronous. The systems of the 1990s and today use memory to filter most reads and buffer writes to the disks. The authors argue that large sequential writes become commonplace motivating the log idea.
Contribution
The basic idea of LFS is appending all file system updates i.e. both data and meta-data into a log like structure. Because LFS appends inode blocks in the log as well it uses a level of indirection via inode_maps. Since most of the inode_map working set can be cached in the memory, thus LFS can perform faster look-ups than naively reading the entire log
1- An issue with using log structure is dealing with fragmentation and freeing of large extents of free space. The LFS solution is to divide the disk into regions called segments. The large size allows segments to amortize seek costs in sequential writes so segments can be threaded easily. This avoids moving around long lived data unnecessarily.
2- A segment cleaning mechanism searches for low utilized segments, and compacts the data into lesser segments, freeing up segments for new logs. To help identifying live data, each segment may contain one or more segment summary tables that provide a back pointer to the file + block number for each block in the log.
3- The cleaning mechanism requires a policy to select candidate pages to compact .The authors systematically simulate the cleaning overheads (write costs) for the common case where portions of the file system (hot) account for most accesses (90%). They develop a scheme that ranks segments based on both their utilization and chances of being further fragmented (estimated by age). Simulations validate that this scheme can achieve better efficiency in writes by incurring a lower write cost.
4- For crash recovery LFS saves checkpoints to a fixed region in the disk. Each checkpoint ends with a timestamp, that allows LFS recovery code to identify if a checkpoint has completed. The checkpoint also stores addresses to inode_maps and a pointer to the last segment. This is used to additionally roll-forward the logs and thus reclaim work done before the crash.
Evaluation
I found their analytical evaluation for cleaning policies interesting and insightful. They clearly show the intuition of how free space can be more valuable in a colder segment. The authors build a production ready prototype which is impressive. The authors use micro benchmarks for small and big file accesses. LFS outperforms UNIX FFS nearly 10x in creating and deleting small files. For large file sequential read LFS performs at par, and for sequential writes outperforms FFS due to batching disk i/o. To assess the cleaning overheads the authors measure a production system over several months, the write costs being quite low. The crash recovery time increase with number of files written in a check point. Also they show that 17% of a log consists of meta data structures such as inodes and other tables. (overhead)
Confusion
How to disk reads work in LFS, if the inode_map is caches in memory won’t it be a limitation if the disk is large ~ 10s of Tb.

1. Summary
This paper describes the design and implementation of monitor model to support large concurrency application on the pilot operating system they are developing using Mesa. The monitor described in this paper exposes several differences in terms of semantics compared to previous work form Hoare, which allows it to be more lightweight and flexible.
2. Problem
The use of monitor as synchronization object for concurrent applications has been widely discussed in literature. The aim of the pilot operating system the authors are developing includes supporting large application with high concurrency needs. They found that old works on monitor are inflexible in the creation of processes and monitors, confusing on the semantics of WAIT synchronization, and does not handle exceptions, which are necessary in large, realistic systems.
3. Contributions
The basic structure of monitor is an instance of a module in Mesa language’s concept, which defines entry procedures that are accessible to all users, internal procedures that are inaccessible directly whose operation have to be synchronized, and some extra helper external procedures. The monitor modules include the code along with the data being protected, and synchronization is handled in the implementation of the monitor using condition variable happening upon the users’ call into the entry procedure. To manage a collection of protected data objects, they introduced a new type called monitor record which includes a monitor lock. The implementation of the monitor can therefore specify the access restriction for each object as a parameter in the monitor record, effectively achieving separate locks for each object in the collection.
They relaxed the semantics of WAIT on condition variable which result in more rich use of it in handling different mechanisms. WAIT is no longer required to task switch to the wake-up process, but rather works as a hint for the waiting processes to re-check the state using a while loop. The relaxed semantics made it much simpler to maintain the invariants of the monitor when the program just has to explicitly check to predicate after the WAIT. The requirement to explicitly re-check the state allow different waiting processes to take different strategies, with some waiting again and other particular process proceeding. Also, the semantics of WAIT allows easy implementation on three exception mechanisms: time-out, abort along with unwind, and broadcast, which NOTIFY in a different way.

4. Evaluation
The authors measured the performance of the monitor implementation in terms of space and time overhead. The overhead of module appears to be acceptable with only a few bytes overhead plus the space for the condition variable. The time overhead is acceptable in most operations they measured, with only over 70% of overhead over normal procedure call, while the FORK+JOIN cost almost hundred times more.
5. Confusion
Shall we talk about the details of the monitor feasibility in implementation?

1. Summary
This paper discusses the experience of the authors in integrating processes and monitors into the Mesa language for concurrent programming. The authors discuss the problems faced especially with the Hoare semantics for monitors and proposes a new semantics for monitors which is more practical.

2. Problem
The authors adopted monitors as the synchronization primitive from a number of alternatives like semaphores, non-preemptive scheduling etc for integrating concurrency into their programming language. However they were faced with a number of challenges during practical implementations of large systems using Monitors. Previous systems using monitors had a set of processes fixed at compile time and a fixed number of monitors both of which were impractical. The semantics of WAIT was not well defined which further led to confusion when used within nested monitor call. Interactions between monitors and other functionalities like exception handling, priority scheduling and I/O must be examined.

3. Contributions
i) One of the main contributions of the authors is the redefinition of the precise semantics of WAIT making it more practical which led to a wider adoption of Monitors in programming languages like Java using synchronized methods. Monitor is a structuring concept that encapsulates shared data and methods that access the shared data into a conceptual entity.
Shared data can be accessed only through entry procedures from outside the monitor or internal procedures from within the monitor. Monitor guarantees that only one thread can be active within a monitor (i.e executing a monitor procedure) at a time by allowing only one thread to hold a monitor lock, thus guaranteeing mutual exclusion. Synchronization between two threads say producer and consumer is usually achieved with help of condition variables within monitor procedures. A WAIT on the condition variable releases the monitor lock which is reacquired while re-entering the monitor. According to the Hoare semantics, when a thread signals on a condition variable, it is forced to release its lock and a waiting thread is immediately woken up and run. This implicitly causes a restriction to the scheduler
and requires an immediate context switch. The authors propose a new Mesa Semantics, which states that the signal is just a hint and the waking process must recheck the state and hence it is ok to wake up a waiting thread at a later random point as decided by the scheduler. In Hoare semantics waking up a waiting thread at a later random point will result in a bug as the condition is not rechecked. This new semantics made the monitors very practical.
ii) Other contributions include proposing a fork -join and detach constructs similar to Unix constructs of fork-join and exec.
iii) Another main contribution is the construct of notifyall or BROADCAST which causes all the threads waiting on a condition to resume. This is particularly useful when there are two threads say a producer and a consumer waiting to enter the monitor and a producer signals and releases the lock. If you wake up the producer it will find the buffer full and wait again. In this scenario it is better to notify both the producer and consumer.
iv) Another construct called naked NOTIFY is introduced when interacting with slower processes say a device driver. In this scenario, naked NOTIFY lets the device driver to execute monitor procedure without acquiring a lock. To deal with the incorrectness that result due to this new semantics, a state is associated with the condition variable that allows signals to wake up future waits on condition variables.
v) The authors also propose ways to integrate priority scheduling and exception handling with monitors

By introduction of new semantics for monitors and condition variables, the authors help the monitors become more practical.

4. Evaluation
The authors perform an evaluation compares space overheads and execution overheads of various mesa constructs introduced for concurrent programming like monitor WAIT, notify, fork+join etc compared to the basic Mesa constructs like procedures and modules. The authors show that new constructs require only reasonable space overhead. The execution time of fork+join construct is quite higher than other constructs but this is comparable to any other process creation overhead say like in Unix. It would have been interesting to see an evaluation that measures performance of systems written with Hoare semantics vs Mesa semantics. Does the restriction on scheduling posed by Hoare semantics make it perform worse than Mesa semantics? Another interesting evaluation would have been to see the overhead of notifyall construct especially say when hundreds of waiting threads are notified and woken up just to block again. A comparison against semaphores in terms of performance and easiness in programming would have been interesting.

5. Confusion
Monitored Objects is not very clear.

1. Summary
The authors work with Monitors in Mesa for the real system Pilot OS keeping local concurrent programming, global resource sharing and replacing interrupts in mind. They evaluate a lot of various methods of signaling in monitor to situations like handling input/output interrupts to cooperative resources sharing among unrelated applications.

2. Problem
The definition of WAIT has had many meanings in concurrent programming. Interaction with process creation and destruction, priority scheduling and semantics of nested monitor calls are some of the challenges the authors attempt to resolve. Their proposed solution also handles timeouts, aborts and other exceptions along with monitoring large number of small objects. Hoare and Howard's signaling mechanisms might wait and restart unnecessarily, Brinch's was be too simple and inadequate and lastly, Signal and Continue was too complex to implement. The shared memory paradigm, monitors are chosen because of they are flexible, robust and naturally enforce structure on parallel programs. Dynamic creation of monitors and handling WAIT in nested monitor calls was not paid attention to in the on-going research then.

3. Contributions
Monitor module is a low level mechanism and has been introduced such that it comprises of various procedures without adding extra synchronization. Entry, internal and external procedures were used for mutual exclusion. If monitor calls WAIT procedure outside the monitor, the lock is not released. There is a two level data abstraction carried out to make a call via an interface to wait on a condition variable. This is to avoid cyclic dependency and impose partial ordering. Starvation is address by high level scheduling with simple and localized verification rules. Signaled processes check only the specific condition and more general conditions are used for NOTIFY. The design also takes care of priority inversion problem, when a process enters monitor its priority is temporarily increased. Exception handling is taken care by UNWIND wherein the nested procedure calls first cleanup and then the main procedure eventually handles the exception. Naked NOTIFY causes an interrupt handler to take over so the actions can be atomic for I/O handling in devices. This sends a notify event without actually acquiring a monitor lock.

4. Evaluations
The authors implemented an operating system and some applications to evaluate their implementation of processes and monitors among the Mesa compiler, runtime package and the hardware. Diversely concurrent applications are implemented on top of this system to validate this system. It would have helped to compare the performance of the more applications on different real time systems too to validate the proposed methodology. The distributed calendar system Violet and an internetwork gateway was evaluated but the details on responsiveness, throughput and number of concurrent requests the gateway can handle is not provided.

5. Questions
What is a wakeup-waiting switch and how can it be used to solve the race condition introduced by the naked notify?

1.Summary
This paper explains the lessons learned in implementing monitors within Mesa on a large-scale flexible system. This paper sheds light into many practical issues associated with monitors that are not clearly resolved in the contemporary work on monitors.

2.Problem
Despite several efforts in the area of synchronization and concurrency, several problems are still remain unaddressed. Problems such as semantics of nested monitor calls, various ways of dealing with WAIT, exception handling by processes in monitors and scheduling of priority inverted processes are open and unaddressed. The paper addressed these issues by providing flexible and programmable synchronization facilities embedded in their Mesa language semantics.

3.Contributions
The main contribution of this paper is that is provides insights into the problems and addresses them, which are not handled by existing literature in monitors. Here’s a summary of them:
* Dynamic process creation and destruction
* Semantics of nested monitor calls
* Defining the meaning of WAIT
* Priority scheduling
* Exception handling (e.g. aborts, timeouts)
* Monitoring large numbers of small objects
* Deadlocks: Avoids recursive entry and prevents deadlocking when the function calls itself
* I/O handling

4.Evaluation
The paper doesn't provide a comparison of the implementation of monitors in Mesa with existing implementation of monitors. It shows that the cost of calling and returning from a monitor entry procedure is 50 ticks, about 70% more than an ordinary call and return.The authors claim that Mesa monitors meets performance expectations and does not involve a significant overhead. Analyzing the costs of other primitives such as WAIT, NOTIFY, FORK/JOIN as well as the storage overheads (relatively small) it is convincing given the amount of functionalities added.

5.Confusion
How are monitors and conditional variables better than semaphores (since one can be implemented using the other)?

summary~
In this paper, the authors present the solution for dealing with concurrent programming in Mesa and some of the experiences gained during this process. The authors examined current approach and then propose their solution over the problems. In the end the authors also present some of the application utilizes their solution.

problem~
Incorporating current concurrent programming facilities into Mesa is hard. Despite that lots of research has been done on concurrent synchronization, but they failed to address some of the issues like WAIT in a nested monitor call, handling of timeouts, priority scheduling, monitoring large numbers of small objects.

contributions~
Monitor creates the respiration of the code, data and synchronization primitives. They defined three types of monitors, Entry, Internal and External. which resemble the semantics of Mesa. The monitors itself can provide some form of synchronization. They also looser semantics of condition variables by looping around the call to wait instead of the Hoare monitors, which helps to simplify the wakeup process, contribute to faster wakeup. Some restriction has also been imposed to cope with deadlock like partial ordering. The UNWIND exception helps to clean up and handle the nested exceptions. In the end the authors also proposed the solution to the issue of priority inversion.

evaluation~
The author evaluate space and time overhead of their implementation. Not much other metrics are provided. They demonstrate their implementation through the example application like Pilot operating system, Violet distributed calendar system and the gateway forwarder, rather than compare to some other existing system.

confusion~
The part of naked NOTIFY is confusing~

Summary:
This paper describes the experiences designers has with designing, building and using a large system that relies on lightweight processes and describes issues with implementing monitors.

Problems:
As more applications start relying more on concurrency , the need for good synchronization mechanisms became more important Monitors were observed to unsuitable for wide variety of large size applications because of assumptions like a fixed number of monitors, no uniformity in definition of WAIT call, fixed set of processes at compile time. There no appropriate priority scheduling and handling of timeouts, aborts and exceptions.

Contribution:
Key controbutions:
i) Easy semantics: each process in Mesa is a procedure , having a dynamic number of processes in the system.
ii) There implementation of condition variable is simple. They use the concept of NOTIFY to provide HINT rather than a guarantee.
iii) Solve the problem of priority inversion by letting monitor inherit the property of the highest priority process and then making the process priority equal to monitor.
iv) Handling of I/O devices using NAKED NOTIFY
v) Handling of exceptions by UNWIND.

Evaluation:
The memory requirement has been evaluated in terms of the data overhead and code. This has been compared to the memory needed by simple procedures and modules. Execution time overhead has also been evaluated for wait, fork/join, switch etc. However, a clear break up and reasoning is missing. Overall impact on eventual performance is not clear to me. Comparison with sequential execution would have provided more insights. Also , process creation is integer multiple times slower than procedure call could be a drawback of this system.

Confusion :

Why is execution time of FORK + JOIN so high for them.

1. summary
The paper explains how monitors can be used in a concurrent programming environment and the problems that can arise therein.The programming environment is the Mesa language. There are many practical issues associated with monitors that have not been dealt with , these are covered in the paper along with how the concurrency principles can be applied to operating systems like Pilot.

2. Problem
In this paper the authors try to solve the following problems in Mesa that were not solved by earlier research paper: dynamic process creation and destruction , semantics of nested monitor calls , defining the meaning of WAIT, priority scheduling,exception handling , I/O. They address these problems and propose different mechanisms by which they can solved.

3. Contributions

A process in Mesa is a special procedure activation that executes concurrent to its caller.It is treated exactly like any other value i.e it can be passed as arguments, assigned to variables.Strict type checking is possible:procedure signature and return type are checked.Exception handling in Mesa propagates up to the root procedure which should catch all the exceptions.A monitor is an object comprised of shared data ,synchronization mechanism and methods accessing the shared data. The entry methods are considered public and the internal methods are considered private.To ensure mutual exclusion , only one process can be inside the monitor and access the shared data.A monitor module is the basic unit of global program structuring.It comprises of public methods , private methods, an entry method and internal methods.

When a process establishes a condition on which other process may be waiting, it notifies the corresponding condition variable. For a waiter, NOTIFY is basically a hint which causes the waiter to be executed some time in the future.There is no guarantee that a waiter executes right after a notify, therefore the waiter needs to reevaluate the condition each time it resumes.Deadlocks are possible through nested monitor calls and it is the programmer's responsibility to be careful not to cause deadlock by using the monitor semantics appropriately.Deadlock can also be caused when single process deadlocks with itself,or when two monitors call each other in a cyclical manner.

4. Evaluation

The paper summarizes the cost of processes and monitors relative to basic mesa constructs.It is shown that the additional cost due to transforming a mesa module to a monitor or changing a normal procedure to a monitor entry procedure are small compared to the normal storage requirements .The execution time /speed of notify and wait depends on the number of processes involved and their priorities The execution time for Fork and Join does not meet the stated efficiency goals and this is attributed to the fact that it was implemented at the language level and not at the machine level.Additionally, the authors could have evaluated how often deadlock conditions occur in practice and how the general performance of the system fluctuates due to their presence.

5. Confusion
Need more clarity on the state of the art when this paper was published.More information about the Mesa language : why it was being used at the time , how did the language evolve with time.

1. Summary
Monitors are high-level language constructs for synchronization. In this paper, the authors talk about their experience in implementing processes and monitors in Mesa, and the resulting learnings, design choices, and refinement.

2. Problem
Monitors provided an attractive framework for reliable concurrent programming, which lead to a number of papers on the integration of concurrency in programming languages. However, Processes and Monitors were not yet fully refined and polished enough to suit a range of applications. Hence, when the authors attempted to pick an alternative and implement it in Mesa, they found that a number of issues had not been satisfyingly addressed or clearly resolved. Some of these issues include Wait in a nested call, Exceptions, Scheduling, I/O integration into this framework, creating processes and monitors.

3. Contributions

Condition Variables - different semantics.
In Hoare's monitors, a process waiting on a condition variable must run immediately after a process signals it, and the signalling process runs again after the waiter completes.
In Mesa, processes waiting on a condition variable are simply woken up, and must contend again for the lock. There is no guarantee on which process will run again.
There are also Timeouts, Aborts, Broadcasts and Yields to handle processes that wait too long, compute too long, etc.
If a monitor calls another procedure, which subsequently waits, lock is not released. If the monitor directly waits, lock is released.
Monitored Records - special constructor for monitor creation.
Unwind - distinguished exception - If any entry procedure is being abandoned, it is given a chance to supply an Unwind Handler to restore its invariant.
Naked Notify - I/O devices notify Interrupt handler without acquiring monitor. Race condition avoided using wakeup-waiting switch, turning it into a binary semaphore
Priority Inversion - Process in a monitor takes monitor's priority.
Clean layered implementation of processors and monitors in Mesa, split across the Mesa compiler, the runtime package, and the underlying machine.
Processes can join on end, or simply detach.
Monitors are modules, only slightly different from regular modules. Entry and internal procedures can are only executed when lock is held.

4. Evaluation
Measurement:
The authors evaluate Storage Costs and execution time, for monitors an monitor entry procedures, compared to regular modules and procedures. Fork + Join are the majorly inefficient functions, which the authors state are due to their implementation in software rather than the underlying machine, and they also state that detach is more popular, justifying their design choice.
They also discuss the implementation and the motivations for their design choices in the context of applications: Pilot, an OS for PCs; Violet, a distributed calendar system; and Gateway, an internetwork forwarder.
Comments:
Mesa cannot check for cyclic calling patterns (to prevent deadlock) at compile time as it has procedure variables.
CVs - since woken processes must check their predicate and contend anew, the calling processes need not know the exact conditions being checked, and can simply use a covering condition. The woken process checks again, which reduces coupling between the two.
Monitored records - Mesa's type system isnt strong enough to make these completely safe.
Mesa processes are cooperative, many design aspects wouldn’t be suitable for general purpose competitive systems.

5. Confusion
Wakeup-waiting switch?
Implementing fork and join in the 'underlying machine'?

1. Summary
This paper describes the issues associated with using Monitors for concurrent programming. With monitors, only one thread has access to shared data at any instant unless the running thread blocks or leaves. The authors implemented their ideas on the Pilot OS using Mesa (programming language).

2. Problem
The use of monitors for concurrent programming has been plagued with plenty of practical issues not discussed in previous studies. This paper discusses certain issues like semantics for nested monitor calls, condition variables, priority scheduling, exception handling, I/O interrupts, programmability, etc... This paper aims at using Mesa to develop monitors for global resource sharing and concurrent programming.

3. Contributions
Programmability: Implicit inclusion of CV and lock within monitors obviate the need for additional synchronization primitives.
Context Switches: Instead of immediately switching to a waiting process on a signal, the new design would queue the process on the ready queue and continue to run thereby reducing the number of context switches.
Abstraction: 3 kinds of procedural abstractions:-
- Entry: Called from outside the monitor to gain access
- Internal: Called only from procedures within the monitor
- External: Called from anywhere
Deadlocks: Implementing partial ordering prevents deadlocks caused by cyclic dependencies. Breaking monitors into smaller parts prevents order dependent deadlocks.
Use of Mesa (unwind mechanism) provides exception handling and the utilization of multiple monitors increases concurrency.

4. Evaluation
The authors evaluate their design along the space and time dimensions to compute the associated overhead. Space overhead is tiny while a monitor call+return is 70% more expensive as compared to its equivalent. The authors implemented Violet (distributed calendar), Gateway (internetwork forwarder) and Pilot to explain the new constructs. While most of the paper is focussed on the implementation, the evaluation doesn't detail the throughput or latency metrics of using the new design. Also, there is no comparison of monitors against traditional mechanisms like semaphores.

5. Confusion
Explanations around naked notify and the race condition in class would be helpful.

Summary:
The paper discusses general issues in concurrent programming, provides a monitor implementation to resolve these issues. It basically explains the problems that they faced (timeouts, exceptions..) during implementation of monitors using Mesa and explain the design choices that they’ve made and also talk about solutions to the problems. The performance of the prototype was then analyzed by running concurrent programs on it.

Problem:
Existing concurrency systems had several issues that had not been addressed, which could potentially be done using the message passing paradigm but message passing was not right way. Some of the concurrency related issues in large sized applications that the authors found in monitors that had not been resolved include supporting handling exceptions, a dynamic number of synchronized processes, dynamic monitor creation, handling aborts, priority scheduling.

Contributions:
The author details each of the issues and modifies the existing processes and monitors to provide the following solutions.
For Process creation, Asynchronous procedure call where the new process and calling process exist concurrently. In order to achieve synchronization and concurrency, the 2 processes can be run in parallel or completely independently and this process semantics looks to be a good design choice with Mesa (fork/join). The authors in general avoided the hoare semantics for NOTIFY in CV and now the NOTIFY is a hint and requires re-checking the condition when process is woken up. For Handling Exceptions, as in most modern languages, exception handling is done throughout the calling hierarchy in the implementation and they do it by making an entry procedure, releasing the lock and then generating the exception. Regarding Monitors, In Mesa, procedures of the monitors (modules) basically guarantee mutual exclusion among processes. When a procedure waits on a condition variable, the monitor lock is released. When an external procedure is called, the monitor lock is not released.
Some other problems that has been addressed include, allowing I/O devices to interact with the system without holding any locks, solving the priority inversion problem by allowing the process having access to the monitor to have a higher priority, deadlock avoidance using partial ordering, reducing monitor into smaller parts.

Evaluation:
The author measures performance in 2 fronts, memory footprint and time overhead. The memory/space overhead for the added code and data segments for wait, notify, fork seemed to be low and was not a huge overhead when compared to the existing cost for monitors in Mesa, hence memory is not an issue. Now, with regard to performance/time overhead, fork and join shows poor performance and these were implemented entirely in software and not hardware. Then the author mentions about applications like Pilot, Violet and Gateway and how they used the new implementation and monitors in mesa. But, as it looks obvious, since the paper introduces new constructs, comparison with earlier ones was missing (CV with and without Hoare semantics). Moreover the performance analysis of a range of applications using the new implementation should have been provided I guess. Performance and comparison statistics for the independent modules that have been added, also could have been useful.

Issues:
What is preferred nowadays, Monitors or Semaphores? When and why? Could you explain handling of race conditions in detail in class?

1. Summary
This paper describes the integration of monitors into the Mesa programming language, as well as new semantics for processes and condition variables. Mesa uses each module as a monitor, and gives new semantics for how to handle nested monitor calls, aborts and other exception conditions, and how to interact with process creation.

2. Problem
At the time this paper was written, many systems using monitors had been designed and developed. However, most of them were inflexible: for example, many expected both the number of monitors and the number of processes to be known statically. In addition, many monitor systems did not well handle when a process aborting or failing with an exception. Also, nested monitor calls were handled poorly.

3. Contributions
The paper describes a process mechanism that treats processes as first-class values, which are created with a fork command and any procedure. When and if the value from the process is needed, a join command can be used to retrieve the value returned from the process's procedure. If the value from the procedure will not be needed, a construct is provided to inform the runtime system.

To provide blocking between processes, the authors integrated a monitor into the basic unit of Mesa code structure, the module. Procedures in a module can be of three kinds: 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. This is implemented by using the pre-existing keyword private for private methods, using the pre-existing keyword public for entry methods, and marking external methods with a new keyword.

The paper also describes monitored records, where each object has its own monitor, which allows an arbitrary number of monitors to be used by a program. Each record must indicate which of its element must be protected.

The paper describes a new design for condition variables. In a pre-existing system, a process that is waiting on a condition variable must run immediately when the variable becomes true. In their system, the process is merely notified. This means that wait expressions must be put in loops, not in if-branches. This allows programs to use simpler expressions as condition variables. Communication with input/output devices uses condition variables and a "naked NOTIFY", which serves the purpose of interrupts. This can result in race conditions, but these can be avoided easily.

All of this is implemented as follows. The process management is implemented using four queues, for ready processes, processes with a monitor lock, processes waiting on a condition variable, and blocked processes. The creation and deletion of processes is managed not by the compiler but by a runtime package which is implemented as a monitor. The compiler is modified to recognize the syntax for processes and to check that, for example, an external procedure does not call an internal procedure.

4. Evaluation
The authors evaluate this implementation on microbenchmarks that test both memory and time. They evaluate on the amount of extra memory needed in each module and procedure, and that needed to run processes and monitors. In every case, the total extra memory required is less than 16 bytes. They also evaluate the extra time taken for instructions, procedure calls and returns, and other control-flow actions. All take less than the time of 60 instructions, except for Fork/Join. This is caused by the implementation in software rather than in hardware.

The authors also implement several substantial programs using these mechanisms, including an operating system, a calendar system, and a packet forwarder for a router. While they describe the ease of programming, they give no quantitative benchmarks.

5. Confusion
What exactly is the invariant they are talking about in section 3.1? Could you elaborate on how it is maintained?

1. Summary
The main idea of this paper is the notion of light-weight processes in Mesa and the concept of monitors and condition variables. The authors talk about the problems that arise when monitors are used in large sized real concurrent systems,with the advent of server machines and networking, and explain how these problems are handled for concurrent programming in Mesa.

2. Problem
The authors wanted to add concurrent programming to Pilot OS and since it was written in Mesa they needed to use abstractions for concurrency in the programming language. Monitor-based concurrent programming model has plenty of issues that are not dealt with previous studies, including programmability, process creation and destruction behavior, priority scheduling, exception handle and I/O interrupts. The concept of monitors existed well , but id did not perform well in real systems.

3. Contributions
Mesa supports lightweight processes for providing better performance on currency by enabling easy forking and synchronization, fast performance for creation and switching of processes by using the shared address space. Mesa provides monitor lock for synchronization, which is tied to the module structure of the language making it clear what point of program is being synchronized.Acquire and release lock semantics are provided by the language. monitor implementation avoids any priority inversion by inheriting the priority of the process that has entered the monitor. Another contribution is the notion of condition variables with notify semantics that would cede lock to the waking process. Communication between a process and I/O device can be done using monitors, where the device can notify interrupt handler by naked notification that signals some event has happened.

4. Evaluation
The context switch provided in Pilot is very fast due to the lightweight processes launched. However they implement this for only uniprocessor systems. Process creation is just 1100 instructions with the fast forking mechanism. the time taken for monitor , switching and notify seems to be less with values 50,60 ,4 ticks. The authors do acknowledge possible issues with their implementation of processes and monitors like dangling references to pointers, deadlocks while using recursive monitors and starvation of waiting threads. The authors describe the way in which processes and monitors are used by three substantial Mesa programs: an operating system, a calendar system, and an internetwork gateway.

Summary
The author in the paper talk about concurrent programming in Mesa and share there experience of using monitors. A monitor provides synchronization to shared data by permitting no more than one thread to run within a monitor at any time. The authors have attempted to implement it with the provided features of Mesa Programming Language.

Problem
The paper discusses concurrency in Mesa and mention and address the problems associated with it when monitors are used. Some of the problems include semantics of nested monitor calls, various ways of defining WAIT, priority scheduling, interactions with process creation and destruction and monitoring large number of small objects.

Contribution
The authors in the paper have attempted to support concurrent programming in Mesa using concept of processes and monitors. Rather than message passing they chose shared memory for inter process communication. Monitors are used to protect data and synchronize its access between processes that share it. They describe in the design paradigms of monitors in Mesa such that deadlock is avoided. When a process establishes a condition on which other process could be waiting it notifies the appropriate condition variable. The process waiting on the condition variable will resume when convinient upon recieving NOTIFY. They tackle the problem of priority inversion where processes using the monitor could prevent the higher priority process from running. For which the solution they propose is when a process enters the monitor its priority is increased to that of the monitor. They also talk about splitting monitors to smaller parts to impose partial ordering to cyclic dependency deadlocks. Over all they seem to have done well to justify their design.

Evaluation

The authors show that Mesa's process and monitor model enabled efficient implementations. They have shown the cost of processes and monitors relative to other Mesa constructs such as procedures, simple statements and modules. They present overheads of storage and data of condition variables, Wait/Notify, fork/join pair. They conclude that with exception of fork/join pair the implementation meets their performance goals. I think author could have shown a comparison benchmarks of monitors with semaphores or with message passing system.

Confusion
Is it that current monitors on Traditional OS based on Mesa's design principles ? Can you explain more on Notify, the information conveyed and wakeup mechanism ?

Summary
This paper describes the challenges faced by the authors when using monitors to implement concurrent programming facilities for Pilot, an operating system written in Mesa. The authors identified a number of issues not addressed by contemporary literature on monitors and proposed further design ideas that led to efficient implementation of monitors for concurrent programming in Mesa.

Problem
When designing the concurrent facilities for Pilot written in Mesa language, the authors had the following goals in mind: (1) enable an application to express its inherent concurrency through synchronized set of processes, (2) allow independent applications to share global resources, and (3) replace bulky interrupts with something lightweight software mechanism. However, the contemporary published work on monitors could not help the authors to resolve a number of issues like dynamic creation of monitors, nested monitor call, priority scheduling with monitors, etc., that they were facing when designing a variety of applications for Pilot operating system. Hence, the authors came up with their own mechanisms to efficiently implement monitors in Mesa programming language.

Contributions
According to me, the following are the contributions of this paper:
(1) A simpler semantics within the Mesa language to dynamically create processes and monitors.
(2) Processes, being treated as first-class constructs in the Mesa language, where they are assignable and can be passed around as reference.
(3) The concept of entry and internal procedures in the monitor to enforce synchronization among interacting processes.
(4) A notification mechanism for "hinting" other processes when a lock is available. In case of "naked" notification, notify() can be called without holding the monitor lock.
(5) Resolves priority scheduling conflicts in presence of monitors by granting highest priority to the process that enters the monitor.
(6) A queue based implementation of monitors, where a process is moved between one of the four queues- ready queue, monitor lock queue, condition variable queue, & fault queue- based on occurrence of events.

Evaluation
In their evaluations, the authors have compared the space and time overhead of their process and monitor implementation against the basic Mesa constructs. They have shown that while the space overhead is small, a monitor call and return is 70% more expensive than the normal counterpart. Fork/join call suffer the worst, by being 38 times more expensive than a normal procedure call. Finally, the authors demonstrated the use of monitors for building various heavyweight concurrent applications like Pilot- a general purpose operating system, Violet- a distributed calendar system, and Gateway- an internetwork forwarder. Although through their evaluations, the authors have fairly demonstrated how they were able to achieve their goals, but it would have been also good if they could have provided results for standard benchmark workloads.

Confusion
Could we go over the details of monitored objects and their implementation, in the class?

1. Summary

This paper discusses the extensions made to the Mesa language for controlling concurrency using monitors for local concurrent programming and global resource sharing. Several issues not previously addressed in designing monitors have been addressed here. The monitors have been fully implemented and their performance analysed.

2. Problem

The existing concurrency options mainly message passing and shared memory did not provide all the required features. Problems associated with the monitors like dynamics of process creation, semantics of nested monitor calls, defining meaning of WAIT, priority scheduling, exception handling, monitoring large numbers of small objects and I/O were not done in the previous papers. This paper addresses these issues.

3. Contribution

Many design paradigms for implementing monitors have been discussed. Shared memory is used for IPC. A new process is invoked concurrently with its caller. Communication with a process is carried out similar to procedure communication. A monitor in a WAIT releases the lock. When control leaves the monitor, the invariant must be established before returning or before doing a WAIT. Whenever control enters the monitor, the invariant can be assumed at the start of an entry procedure or after a WAIT. Condition wait, notify and broadcast were also described. Mesa associates 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. This way, it does not allow more senior threads to obtain the lock thereby preventing starvation. Mesa uses the procedure call process to control the processing of exceptions - they are either run concurrently or are separate processes. This is similar to exception handling in Java. The authors also describe the way in which processes and monitors are used by the Mesa program.

4. Evaluation

The authors implementation of processes and monitors is split equally among the Mesa compiler, the runtime package and underlying machine. The storage cost of the program was determined. The storage costs are small compared with the actual program and data storage. The authors also note that the implementation has met the performance efficiency goals, with the exception of fork and join.

5. Confusion

Monitor records

Summary : The authors in this paper discuss the design of concurrent programming constructs of a new operating system, Pilot. They achieved this by combining processes and monitors using semantics of the Mesa language. Mesa language is touted to be flexible with provisions for procedure calling and process abstractions. The authors also discuss the problems they aim to solve such as timeouts/aborts, device interrupts and priority inversion. Further sections in the paper include implementation details and evaluation details from a storage and execution environment perspective.

Problem : The conventional systems at that time adopted non-preemptive mechanism to execute critical regions. This had many drawbacks such as absence of dynamic process and monitor creation, possibility of deadlocks due to WAIT in nested monitor calls, exception handling, priority inversion, lacks of ways to timeout or abort processes. The authors aimed to address the above problems by building a system with goals such as local concurrent programming, global resource sharing that allows applications running on the same machine to share resources and replacing interrupts by directly waking up relevant processes and avoiding the path of a separate interrupt mechanism.

Contributions :
a] Monitor modules by defining monitors as an instance of Mesa module with entry(used to gain access to the monitor), internal(can be accessed only inside the monitor) and external(can be called from anywhere) procedures. This was implemented using a condition variable and lock.
b] A special unwind mechanism enabled processes to clean up and restore monitor invariants prior to exiting during a computation abort or while handling an exception.
c] Priority inversion was avoided by temporarily bumping the priority of the monitor holder to maximum priority of a process, which would have earlier entered the monitor.
d] Fewer context switches were ensured by placing processes in the ready queue instead of executing it immediately when it is signaled in the monitor.
e] Deadlocks avoided by imposing partial ordering on resources and not using mutually recursive monitors.
f] Notify semantics: In Mesa, notify is analogous to ‘hint’ which causes the waiter to be executed in the future and there is no guarantee that waiter executes right after notify, this reduces context switches.
g] Timeout, abort and broadcast are also defined as alternatives to Notify.
h] Multiple monitor instances are used for objects in place of one monitor handling multiple objects, which improved concurrent accesses.

Evaluation : The authors evaluate Pilot by providing cost for their contributions such as monitor modules, entry procedures, fork and join in terms of storage required and compare these measurements to that of standard modules, procedures and call and return semantics. Two bytes of data and code were added by changing module to monitor and changing normal procedure to monitor procedure added eight bytes of code. They also measure and provide cost in terms of execution time for Mesa primitives like monitor procedure, call and return, fork and join, wait and notify. Calling and returning from a monitor takes about 70% more time (50 ticks) than ordinary call and return. Process switch takes 60 ticks inclusive of the queue manipulation and state saving and restoration. The authors also evaluate their system for feasibility and ease of application programming by implementing three complex programs (Operating System, replicated database, and internetwork gateways) using the Mesa concurrency primitives. The authors succeeded in portraying that their implementation of monitors using Mesa was able to solve many existing unresolved issues with monitors. They also were successful in implementing further optimizations to reduce context switches or avoid deadlocks.

Confusion : i] Exception handling and race conditions handling in Mesa is not clear ?
ii] Concept of naked notify and wakeup-waiting switch to solve race conditions ?

1. Summary
This paper focuses on solving the various issues that arise while using monitors for obtaining concurrency. The authors first describe the various issues with the existing approach. Next, the authors give details regarding their solutions to solve the problems at hand in Mesa. Lastly, the authors describe their implementation of the proposed solution known as Pilot OS and evaluate the same.
2. Problem
There were a number of existing issues related to concurrent synchronization mechanisms that had not been resolved in spite of extensive discussion of monitors in the literature. These issues included having fixed number of processes as well as monitors, ambiguity with respect to the behavior of the WAIT call inside a nested monitor call, ordinary exception handling, no clear description of the scheduling semantics as well as priority scheduling and incomplete details of how I/O devices would fit into the framework of monitors. The authors’ main goal was to solve the aforementioned issues.
3. Contribution
According to me, the main contribution of the authors’ was the approach taken by them to solve the various issues in existence. The authors systematically list out and describe the various solutions to the issues identified in great detail. Firstly, the authors describe how processes can be created in a similar way as procedure call. Next, the authors go on to describe the various monitors procedures that can be used to access the data protected by the monitor – entry and internal. Along with these two monitor procedures that require a monitor lock to be help, a monitor module also consists of external procedures, which are nothing, but non-monitor procedures. Another important contribution is the use of UNWIND that is a distinguished exception to handle exceptions in case of an exception in a nested case. Another interesting aspect of the paper is the one wherein the authors describe new NOTIFY semantics, which are different from the Hoare’s semantics. Hoare’s semantics required the notified process to run immediately whereas the proposed semantics stated that NOTIFY should be treated merely as a hint and the process would need to re-evaluate the condition before the process would wake and start execution. Alternatives to NOTIFY such as timeouts, broadcast and abort were discussed. Lastly, the authors also provide a solution to solve the priority inversion problem that existed and also introduced the concept of naked NOTIFY for communication with I/O devices.
4. Evaluation
The authors evaluated their proposed solution in terms of data as well as program storage overheads along with execution times for the various constructs. Though the authors did a commendable job of giving details regarding how processes and monitors could be used by real applications, I feel that it would have been nice to see a comparison with other existing synchronization mechanisms such as semaphores. It would have been ideal to compare the performance of the real applications on different systems too to validate the proposed methodology.
5. Confusion
Could the concept of naked NOTIFY be discussed in class? How do monitors compare to semaphores in performance?

1. Summary The authors discuss their experiences integrating monitors and asynchronous processes into the semantics of the Mesa language. In particular, they discuss practical modifications they made to the theoretical constructs they made in their implementations, including a reformulation of the semantics of monitors and condition variables.
2. Problem There are a wide variety of programming constructs which provide mutual exclusion, but integrating synchronization constructs into the syntax and semantics of a programming language like Mesa is a challenge. Semaphores are powerful and general, but are easy to use in an unstructured way. Cooperative multitasking obviates the need for mutexes and signaling, but yields brittle solutions incompatible with key features, like paged virtual memory. Message passing is viable, but it's not clear how to directly integrate it into Mesa's type system. Monitors are a promising solution, as they map directly onto Mesa's units of structure - modules and procedures. However, the practical concerns of software implementation complicate this mapping. Hoare's condition variable semantics yield unnecessary overhead by immediately waking signaled processes, and exception handling is challenging in a hierarchy of processes which may hold arbitrary monitors.
3. Contributions Mesa programs are structured in terms of modules, which are collections of procedures that operate on shared data. To extend Mesa with first-class procedures, the authors add a new fork construct that allows (almost any) procedure to be invoked as an asynchronously executing process; the fork construct returns a handle for the executing process. The caller of the fork can wait for the process via a join call, and can obtain the return value of the procedure from which the process was created (or the caller can completely detach the process, letting it run indefinitely). To provide synchronized access, modules can be declared as monitors, which allows the language runtime to enforce some fundamental synchronization invariants in a way that is not possible with e.g. semaphores. A monitor exposes a set of publicly accessible "entry" procedures and retains a set of private "internal" procedures. A process invoking an entry procedure obtains a module-wide lock, which it yields upon exit. If a process in a monitor needs to wait on a state change, it can wait on a condition variable, at which point it yields and releases the monitor. To eliminate unnecessary context switching, Mesa's condition variable semantics treat a signal to a condition variable as a "hint." The signaler continues, and waiting processes are not woken immediately, and they need to validate the state after waking and before continuing. The authors treat deadlock as programmer error, and provide advisory rules on how to avoid it. They also allow for the creation of an arbitrary number of synchronized objects by extending the type system with "monitored objects." Priority inversion is resolved by giving a process executing in the monitor the priority of the highest priority process in the queue. As hardware notifications occur outside of monitors, inducing race conditions, hardware condition variables are converted to binary semaphores.
3. Evaluation The authors show that adding the new constructs incur a modest cost per procedure and module, and that the process manipulation primitives are similarly inexpensive in terms of space. The synchronization primitives incur a low cost - at most 60 cycles, while fork and join cost roughly a thousand cycles. This seems consistent with process management costs on other systems. The authors also discuss the implementation effort for various systems, and conclude that Mesa's process and monitor model enabled efficient implementations. I would have liked to see more robust performance benchmarks, perhaps for operations on non-trivial data structures, with a large degree of lock contention and asynchronous I/O. The authors assert that monitors are the best fit for Mesa, and while that seems reasonable from the standpoint of language aesthetics, it's not clear that it's true from a performance and engineering standpoint. It's not clear without a comparison with e.g. message passing or semaphores.
4. Confusion How much of what we consider traditional OS functionality is provided by the Mesa runtime? How much of the Mesa runtime is provide by microcoded CPU operations? What generalizes to a less specialized CPU architecture?

1. Summary
The paper provides a fully fleshed out implementation of monitors. This leads to the authors encountering various issues not handled by previous work. They then discuss possible solutions to these problems and the reasoning for the design choices. A prototype is implemented over the Mesa language and its performance is analyzed.
2. Problem
Monitors were discussed in literature and were gaining popularity as an apt encapsulation of concurrency. However various questions that would arise in real systems had not been dealt with. The semantics of nested monitor calls, exact expectations of the WAIT call, concurrency with priority scheduling as well as exception handling in a concurrency aware language. Solving these problems would preclude any adoption of this concept in real world systems.
3. Contribution
The authors designed the concurrent programming facilities for Mesa using the pre-existing module abstraction. Their primary contribution was a summary of what a monitor should and should not provide. This helped separate responsibility between the application programmer and the concurrency framework. The authors defined a monitor module as basic unit for structuring locking code and data. The monitor guaranteed atomicity but left the onus of deadlock avoidance on the application developer. Similarly monitors provided a special UNWIND exception to signal a module cleanup (and release of any locks) but did not handle the case when a corresponding handler was not present in an entry function. The paper also covers the design decisions around condition variables and corresponding wait and notify functions. In each of these discussions the authors present only the basic synchronization primitives within the modules leaving all policy at the hands of the developer. This aids in a general design that is lightweight and easily flexible to the needs of each possible application. However, a few corner cases are left unsolved such as the race condition between a naked notify and the predicate check before the WAIT call.
4. Evaluation
This paper differs from various others in that the authors provide a space analysis along with a time analysis of the various constructs introduced. However, these are not compared against any other synchronization primitives such as Hoare’s work and hence do not give much context about potential bottlenecks in the system (although FORK and JOIN seem to be bottlenecked due to their implementation in software). The authors then describe their experience in implementing various applications such as Pilot (an OS) and Violet (a distributed system) these lead to some credence to their claim that this system was practical from an application designer point of view. However, their reliance on changes in hardware to implement the most performance critical section would encounter a lot of inertia as the changes were not isolated in software and would require disparate entities to work together to solve a problem which can be solved entirely in software.
5. Confusion
I am not sure how external procedures can be implemented without locks, even in the example given, the expand procedure would need to hold the monitor lock when copying data to the new block to ensure that the data on the new block is consistent and no allocate procedure gets storage on the old block.

1. Summary
This paper talks about us some of the problems that exist in concurrent programming using a high level programming language called Mesa. One of the main focus of the paper is about how monitors can be used to solve some of its issue. Some of the other features mentioned in the paper are its representation and use of light-weight processes, conditional variables and priority scheduling. They then talk about its implementation (pilot OS) and evaluate its performance and storage overhead.

2. Problem
During the time of release of this paper there were many issues (things unclear) relating to use and functionality of monitors which could not meet the needs of real-world applications. Some of these were related to handling exceptions, scheduling, working of I/O devices, using fixed amount of processes and monitors, working of wait call in monitor being unclear etc.

3. Contributions
Some of its major goals were to provide local concurrent programming, global resource sharing and replacing interrupts
. They implemented their idea in Pilot OS and other application using Mesa language. I think the main contributions of this work was modifying processes and monitors in Mesa to support concurrent programming. They chose to use shared memory for IPC and the processes were lightweight and could be run using special procedures activations (fork/join). Their exceptional handling method is similar to how its done in languages like C and Java. Monitors are used to protect data and synchronize its access between processes that share it. A monitor module has 3 procedures: entry(lock acquiring), internal(private, called from inside) and external (non-monitor procedures). They then explain the main features of monitors like how it avoids deadlock(partial ordering), replicating monitors with monitored record and how exceptions are cleaned up using unwind. They also talk about how conditional variables are used and integrated with monitors. They discuss how notify signal can be used as hint for waiting process and what alternatives exist. They also justified why they used mesa semantic instead of hore. The paper in general for the most part was able to justify all its design choices. They finally talk about the implementation and features (avoid starvation) of priority scheduling.

4. Evaluation
The main point that I got from the evaluation section was that the additional(overhead) costs involved were not significant in both execution time and memory. They also talk about some implementation examples where they discuss the experience involved in designing those applications/systems, issues in them and the overhead involved. It would have been nice to see how it compared to other monitoring constructs for different applications with different behaviors.

5. Confusion
Are monitors still preferred over semaphores? I did not completely understand naked-notify and the race condition mentioned in the paper?

Summary
The paper details the effort on the design, development and evaluation of processes and monitors in the Mesa language with respect to the objective of facilitating reliable concurrent programming.

Problem
Existing monitor implementations in Mesa had large scale drawbacks for handling concurrent applications that varied in size and functionality, due to factors such as 1. The requirement to fit into well-defined Mesa modules, 2. Statically defined parallelism (number of processes and monitors fixed at compile time), 3. Ambiguous handling of WAIT for nested monitor calls 4. Graceful exception handling (that interacts properly with monitors), 5. Lack of agreement on scheduling semantics for waiting on condition variables, 6. Lack of attention to interaction between monitors and priority scheduling 7. Incomplete functionality for I/O handling in the framework of monitors and condition variables.

Contribution
The design proposed by the authors allows asynchronous creation and execution of processes from their callers. It considers processes in the same vein as procedures, as parameters can be passed to processes and the results of processes can be retrieved. The low overhead of considering a procedure as a process and the moderate cost of process creation / destruction facilitate dynamic process creation, and solving of synchronization problems by using monitors. Monitors provide synchronization amongst processes sharing data by unifying synchronization, shared data and the body of code performing these accesses. The monitor is implemented as a special Mesa module, whose entry and internal procedures run with the monitor lock being held to ensure mutual exclusion over the shared data. This lock is held until we return from the monitor procedure or until a WAIT call is encountered, which causes the monitor to relinquish this lock. Deadlocks can occur when monitors are incorrectly programmed; however, Mesa provides an environment which allows easy deadlock avoidance. Monitored records include a monitor lock and represent the protected data of a monitor. Exception handling is managed using the default Mesa exception handling mechanism, with the addition of the Unwind exception, which allows process cleanup (such as restoring the monitor invariant) before an activation is destroyed. The Mesa design treats Notify on a condition variable as a hint to a blocked process (on the same condition variable) 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. Timeout, abort and broadcast are additional ways to handle processes blocked on a condition variable. 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. Subversion of priority assignments by monitors is handled by associating with each monitor the priority of the highest priority process that ever enters it.

Evaluation
The authors implement processes and monitors by splitting the implementation between the hardware, runtime package, and the compiler. The runtime dealt with process creation and destruction through the Process module, while the hardware dealt with process scheduling and monitor entry/exit. The compiler was used for code generation and performing static checks. This split was based on frequency of use of a particular functionality, instead on the cleanliness of its abstraction. I disagree with this approach as it required the implementation to have extensive Hardware support through creation and maintenance of the ProcessStates table and the ready, monitor lock, condition variable and fault queues.

Two aspects of performance were attempted to be measured. The first was the storage cost analysis, which showed encouraging results – the code and data overhead of different implementation constructs was low. On the other hand, the execution time analysis was disappointing – it was not comparative (against other implementations), the hardware on which these tests were performed was not described, and the implementation of the required hardware support was also not touched upon.

The authors then describe how their monitor and process implementations have helped in constructing concurrent programs such as the Pilot OS, the Violet distributed database and the Gateway internetwork forwarder.

Questions / Confusion
1.Monitored records

Summary
The paper outlines the integration of processes and monitors into the Mesa language for supporting concurrent programming , global resource allocation and a means for replacing interrupts. The paper describes various options considered for an appropriate implementation of monitors and condition variables and gives an overview of the semantics of processes, monitors and condition variables.
The Problem
Monitor based concurrent programming was plagued with a lot of practical issues like semantics of nested monitor call, various definitions of WAIT, priority scheduling, handling of timeouts,aborts and other exceptional conditions, interactions with process creation and destruction, monitoring large number of small objects, fitting of a process in a
Contributions
The paper provides a solution for a variety of problems which were hitherto inadequately dealt with
1.Monitors provide a mechanism for protected access to shared data, which can be accessed only from the entry and internal procedures of the monitor. Actions which does not require to hold the monitor lock can be performed in external procedures of the monitor. If a set of objects function independently, monitored objects can be used so that each object can function concurrently on their set of shared data. 
2.Process creation is simplified- any function can be prefixed with fork.
3.Outlines a way to tackle the problem of priority inversion via priority boosting.
4.Introduces a new construct called monitored records in oder to support monitor objects which is a dynamic collection of shared objects.
5.For exception handling, the paper suggests that first mutex should be released and then the exception should be handled. Another feature is the graceful UNWIND handler is used to handle exceptions in nested procedure calls.
6.It uses a concept of notifying instead of signaling the conditional variables. Three alternatives to notifying is also provided namely timeout,abort and broadcast. Communications between process and device can be implemented by monitor. Device can notify interrupt handler by naked notifications that signals some event has happened. It is called naked notification because the device does not hold a monitor lock , hence race conditions can take place.
7.The paper provides solution for many aspects of a monitor almost all of which is adapted for Java monitor.
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. However performance analysis on deadlock and race conditions is missing from the evaluation section, the entire discussion is mostly on the implementation issues faced rather than quantitative performance measurements. Also a break up of the total ticks in monitors and corresponding reasoning for the additional ones would have been a valuable addition.
Confusions
1.What is the wake-up waiting switch in Naked notify?

1. Summary
The authors provided a first real implementation of Monitors which are high level constructs to provide synchronization. Their implementation was based on Mesa language. They also discuss about solutions which came along with the way during the practical implementation and provided solutions for them.

2. Problem
The authors listed several problems such nested monitor calls, handling WAIT calls, interaction of priority with the locks, exception handling and large number of synchronization modules for objects. Existing literature discussed these problems but did not adequately dealt with in a real life implementation.

3. Contribution
The authors came up with a real time implementation of monitors in which they addressed a number of issues, as discussed earlier. Some of the notable ones were:
- Handling a variable number of monitors
- WAIT in a nested call.
- Scheduling with process containing priority.
- Synchronizing with I/O devices.
The authors provided a high level construct for create and detaching a process - which was done in a similar construct as procedure call which can be passed arguments. They describe the routines in a monitor - entry (which require a lock and are public procedures), internal (also require locks and can be called only from the entry procedures) and external (public procedures and doesn’t require a lock). These functions provide a complete encapsulation for implementing locks. They also discuss about the rules to avoid deadlock - avoid circular dependency. Monitored objects talk about the scenario where multiple objects needed locks. This can be handled by either using a common lock (which would limit the concurrency) or use multiple locks (which would encompass several extra abstractions). They suggest to use the locks as arguments to the master construct and hence avoid the need for multiple instantiation of locks. UNWIND - was an exception which was generated when a process in nested call frame faulted while holding a lock. This would provide a chance to the call stack to handle the exception, otherwise it would lead to a deadlock situation. They also discuss about using Condition Variables (CVs) and the associate race conditions with them after a signal was issued but before the process could wake and resume, the invariant was reverted. This lead to essentially change conditional check semantics from ‘if’ to ‘while’. Alternatives to NOTIFY were discussed as either Time out, Abort or Broadcasting mechanism to resume waiting processes. Naked NOTIFY calls from the device driver were introduced otherwise it would limit the best worst time performance. To handle priority inversion, they suggested to increase the priority of the blocking process or that of the monitor, so that the process could complete the critical section sooner. Overall, this was one of the few designs which is still used in many real world applications and studied as an integral concept in Operating Systems introductory class.

4. Evaluation
Although the authors profile the memory requirement and the time to execute each basic operation (WAIT, NOTIFY, FORK), they did not compare it with existing synchronization constructs such as using semaphores and conditional variables. Also, they did not explain the choice of hardware which can lead to variation in numbers. The analysis provided on real life applications such as Pilot operating system, Violet - a distributed database manager and Gateway suggest that it was indeed a practical solution.

5. Confusion
I did not fully understand the concept of monitored record and wakeup-waiting switch.

1. Summary
This paper describes the experiences and challenges faced by the authors in implementing monitors in Mesa. It discusses the design choices they made in order to integrate monitors as a synchronization tool in Mesa semantics and the practical problems they faced like timeouts, priority scheduling, exceptions. They validate their design by running complex concurrent programs on it.

2. Problem
The authors wanted a system that supports concurrency while at the same time meeting requirements of handling many practical issues. Message passing paradigm could potentially achieve these goals. But it was not a match for their existing infrastructure. Monitors were gaining popularity in research as they were flexible, robust and naturally enforce structure on parallel programs. While reviewing the existing literature on monitors, the author found that the number of issues related to supporting synchronization techniques had not been resolved adequately by the research literature in this field. These included supporting a dynamic number of synchronized processes, dealing with WAIT calls inside nested monitor call, handling exceptions and aborts as well as providing priority scheduling.

3. Contribution
The authors decided to implement their version of monitors. The major contribution of the paper lies in the insights they provide in order to tackle the issues described above. They discuss the process and semantics of the Fork and Join operation. While developing the monitor, they deviated from the Hoare semantic and implemented the notify to only be a hint that something might have changed. As a result, the process must recheck the state on wake up. This semantics helps avoid the complex implementation aspects of Hoare semantics. The reduced context switches thus help to boost the performance. They tackle the problem of priority inversion by allowing the process which has access to the monitor to be elevated to higher priority. The paper includes a discussion on deadlocks and how to avoid it. They talk about avoiding recursive entry procedures, by imposing partial ordering for cyclic dependency deadlocks and by breaking monitors into smaller parts for order dependent deadlocks. To handle exception they make an entry procedure to restore to invariant, release the lock, return with error, and then generate the exception. Improved performance between processes running at different frequencies is achieved by naked NOTIFY.

4. Evaluation
The authors discuss the storage and data overheads of constructs such as condition variables, WAIT and NOTIFY. They also discuss the execution time of these constructs. Finally they validate their design by running complex parallel applications.

5. Questions
I did not understand monitored records and the discussion around race conditions and naked notify.

1. Summary
This paper describes the experiences and challenges faced by the authors in implementing monitors in Mesa. It discusses the design choices they made in order to integrate monitors as a synchronization tool in Mesa semantics and the practical problems they faced like timeouts, priority scheduling, exceptions. They validate their design by running complex concurrent programs on it.

2. Problem
The authors wanted a system that supports concurrency while at the same time meeting requirements of handling many practical issues. Message passing paradigm could potentially achieve these goals. But it was not a match for their existing infrastructure. Monitors were gaining popularity in research as they were flexible, robust and naturally enforce structure on parallel programs. While reviewing the existing literature on monitors, the author found that the number of issues related to supporting synchronization techniques had not been resolved adequately by the research literature in this field. These included supporting a dynamic number of synchronized processes, dealing with WAIT calls inside nested monitor call, handling exceptions and aborts as well as providing priority scheduling.

3. Contribution
The authors decided to implement their version of monitors. The major contribution of the paper lies in the insights they provide in order to tackle the issues described above. They discuss the process and semantics of the Fork and Join operation. While developing the monitor, they deviated from the Hoare semantic and implemented the notify to only be a hint that something might have changed. As a result, the process must recheck the state on wake up. This semantics helps avoid the complex implementation aspects of Hoare semantics. The reduced context switches thus help to boost the performance. They tackle the problem of priority inversion by allowing the process which has access to the monitor to be elevated to highest priority. The paper includes a discussion on deadlocks and how to avoid it. They talk about avoiding recursive entry procedures, by imposing partial ordering for cyclic dependency deadlocks and by breaking monitors into smaller parts for order dependent deadlocks. To handle exception they make the an entry procedure to restore to invariant, release the lock, return with error, and then generate the exception. Improved performance between processes running at different frequencies is achieved by naked NOTIFY.

4. Evaluation
The authors discuss the storage and data overheads of constructs such as condition variables, WAIT and NOTIFY. They also discuss the execution time of these constructs. Finally they validate their design by running complex parallel applications.

5. Questions
I did not understand monitored records and the discussion around race conditions and naked notify.

1. Summary
In this paper the author present their experience with using monitors for concurrent programming in Mesa. They highlight the issues encountered while implementing monitors in Mesa and resolve them.
2. Problem
The monitors have been discussed in literature a lot for handling concurrency. However the existing implementation of monitors had several flaws that made them unsuitable for use in real systems. There were issues with semantics - behaviour of nested monitor calls and WAIT was not consistent across environments. Handling of timeouts, aborts and other exception conditions was not satisfactory. Interaction of monitors with scheduling logic and process creation/destruction was not well defined. Lastly, constraints imposed on number of monitors and processes limited the use of monitors in large application space.
3. Contributions
The authors explain each of the issues mentioned above, and refine processes and monitors to tackle them for efficient concurrent programming. Starting a process is done by a concurrent call. Concurrency is controlled by letting the child process run in parallel and join the caller, or detach itself to run standalone. They also implemented monitors as modules which act as basic program structuring entities as they automatically acquire and release locks. There are three types of procedures in a monitor - entry procedure which is guarded by locks, internal procedure that can be called only from inside the module, and external procedure which is exposed to outside world and operates without locks. The authors redefine the semantics of condition variables. Previously, Hoares’ semantics for condition variables used complicated scheduling constraints. Here, the wake-up of thread is treated as a “hint” - a woken thread acquires lock and checks upon condition before taking desired action. This simplifies scheduling and also makes it easy to introduce more hints for timeout, abort and broadcast. IO devices also interact with the system and notify condition variables without acquiring any locks. They also provide solution for priority inversion problem since the monitor’s priority is raised by using the priorities of contenders for the lock. The paper also takes care of exception handling as it can be propagated through the calling hierarchy back to the root where it can be handled.
4. Evaluation
The authors ran experiments to measure the space overhead of the monitor implementation and time overhead of basic operations like process switch, notify, fork/join and wait. Most constructs perform well except fork/join - these two constructs were implemented in language and not in the underlying machine which leads to the observed degradation in performance. The 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. However, the evaluation lacks comparison with other implementations e.g. some comparison against Hoares’ implementation of condition variables would give some context in terms of how their implementation performs. Another possible study could have been some measure of monitor overheads under contention and possibly compare it with other works.
5. Confusion
The wakeup-waiting switch helps avoid race condition between processes in naked notify. How does that exactly work?

Summary
This paper talks about adding concurrency extensions to the Mesa language. It is especially relevant for defining practical semantics for conditional variables, also known as Mesa semantics
Problems
The designers identified several issues while implementing monitors that were not covered well in literature. To properly interact with Mesa’s language features monitors and processes had to support dynamic creation and interact with the exception system. Additionally they had to deal with semantics of nested monitor calls, timeouts, object arrays and priority inversion. A second problem had to do with defining the semantics of condition Wait. Hoarse’s condition variable signal required the system to atomically transfer the monitor to the waiting thread. This involved complicated process scheduling issues and extra context switches.
Contributions
The paper broadly studies practical issues with monitor implementations :
- Monitors: The monitor abstraction associates shared data with synchronization ensuring only one process is in a monitored procedure at a time. Mesa monitors were implemented as modules with three types of procedures - internal, entry and external. External procedures are nice for implementing a sequence of operations on the monitored data of which only some need synchronization. Mesa also included a return with error call so a monitored (entry) procedure could release the lock before generating an exception.
- Nesting: The monitor basically tries to enforce an invariant on the data unless some process is presently in the monitored call. The programmer must ensure this holds before calling a wait and thus monitor lock can be released. The same is not true while making a nested monitor call as this would add undue burden. Hence, while making nested calls the calling monitor lock is held. Note that this adds the possibility of deadlock due to circular calls or dependencies.
-Condition waits: Condition waits were conceived as a way for processes to wait for a certain pre-condition to hold. In the original design this condition is assured to be true when the process wakes up i.e nothing interferes between the signal and wake-up. Mesa cleverly relaxes this for better implementation freedom. A notify rather than a signal is used as hint that the monitors state has changed. Mesa requires the waiting thread to check the condition after wake-ups. This has benefits such as simpler scheduling. Specifically this allows the implementation of timeouts as simply waking up the thread and more graceful aborts. It also allows for a broadcast hint that wakes up all waiting threads which then check more specific conditions.
-Others: Since I/O devices cannot support direct mutual exclusion Mesa uses a notion of naked notify viz a condition wakeup. To avoid race conditions it uses a binary wake switch variable akin to a binary semaphore. Priority inversion related to holding monitors is solved using a priority inheritance like scheme. .
Evaluation
There are two parts to the evaluation. The first quantifies the space and time overheads for the concurrent programming facilities. The space overheads portion was interesting but clearly not quite relevant these days. The time costs are compared to that of a null procedure call which is good. The overheads seem reasonable for most primitives thought that is because process scheduler is implemented in hardware using micro-code. Modern parallel systems have much higher overhead for thread creation making such a model hard to use. The second part looks at experience for building real applications. One example, Pilot shows that porting efforts for a concurrency where simplified by the notion of monitors.
Confusion
Is there a race condition possible in Hoarse’s wait primitive, where two conditions are signaled at the same time?
I didn’t understand their syntax for monitored records too, are there two locks in this case?

Summary
The paper presents mechanism to support the Concurrency programming in Mesa using Monitors, Condition Variables. The paper presents detailed implementation of monitors,condition variables in Mesa, and explains handling of different issues related to it , like deadlock in priority scheduling and handling nested monitor calls etc. Other details being different situation of deadlock while support concurrency and how to handle those.
Problem
The problem being to provide concurrent programming facility in Pilot operating system running on mesa language using monitors. But lot of the issues in related to monitors were not addressed - Dynamic creation of process, Creating monitors based on the amount of data, Wait is nested monitor call, Handing exceptions, priority scheduling with monitors.
Contributions
Main Contributions of this paper are
1] First implementation of Monitors in Mesa which help in synchronization over accessing shared data when there are multiple process running in parallel. The paper gives detailed implementation of monitors using entry procedures, monitor locks(invariants),Notify.
2] Correct implementation of Condition variables(CV) in Mesa which is different from Hoare’s definition of CV. Making sure that the critical section is entered by only one process at a time by ensuring the waked process checks condition before resuming
3] Naked Notify to interact with I/O devices
4]Avoiding deadlock in case of priority scheduling by raising the priority of process acquiring lock.
Evaluation
The paper presents the code and space overhead of all the Monitors,Wait, Notify, Condition Variables. Other details are the implementation details of 3 application which used the monitors and condition Variables :Pilot OS, Violet: A distributed Calendar systemGateway:An Internetwork Forwarder. What i find missing in evaluation sections is any details of performance of applications with monitors, CV's.
They have just given the details of what problem did they face while implementation of mutual exclusion, Concurrency , and what situations did they face Race condition. More detailed evaluation of in what percentage of concurrency was achieved, stats on the situations where race condition was avoided would be better.
Confusion
Can you please explain what are monitored objects.

1. Summary
The paper talks about the design experiences of implementing monitors and processes in Mesa. Their design parameters various real time concurrency issues like overhead of creating processes, simplistic code structure, lock granularity, etc. and explain how their model adapts to these variables.

2. Problems
Monitors have been proposed a solution to handle concurrency in shared memory model. However the authors feel that the idea proposed in the literature are too naive and do not consider real time problems for direct adoption into an OS. For example, any process design should fit in the programming paradigm of mesa, priority scheduling, handling WAIT in nested monitors, handling exception at multiple levels, cost of creating process and programming structure of process creation. The paper is addressing to these issues and how they can adapted to implement in mesa.

3. Contribution
Mesa supports a low overhead process creation and the programming structure makes it similar to procedure activation which would run concurrently with the caller and processes are dealt like first class variable. Mesa implicitly takes care of return values and also supports detachable process which exits without returning any value. These are automatically destroyed after execution. Debugging is complex when there are nested process invocation and error handlers may not be sensible if only the root processes handle the error. Hence the author’s design makes sure that each process at various levels in the call graph is given a chance to handle the error such that valuable information is passed to the user. The scheduler places the processes in four circular queues, which provides simple and low overhead insertion and deletion to the queue. The process are sorted by priority within the queue. The paper also talks about priority scheduling for allocation processors to the processes.
The authors have chosen monitor over semaphores for concurrency management because monitors provide better structuring than latter. Internal procedures of a monitor can wait on condition variables and will be woken up by NOTIFY. In this design, NOTIFY merely signals the waiting process that causes it execution in the near future. The authors claim that this simplifies the design and applications do not have the trouble whether the exact condition needed by the waiter has been established. Mesa employs naked NOTIFY for I/O communications. In this case, the I/O device cannot wait on a monitor lock, it signals waiting threads using NOTIFY when attention is needed. The paper then elaborates possible race condition and its solution.

4. Evaluation
The authors have evaluated the idea by breaking down data and timing overheads involved in basic operations like procedure, FORK+JOIN, etc. The authors state that their design is able to meet the timing requirements with the exception of FORK+JOIN case. However they do not give the reason behind this behaviour. They also briefly describe their learnings from implementing Pilot, Violet and Gateway.
The evaluation seems to be insufficient. The motive of the paper was that the existing literature works were not considering real time scenarios and hence the authors went ahead with modifying many existing techniques to suit concurrent execution model. But they don’t evaluate the design by running actual programs concurrently. Features like monitor objects which aim at easy creation of shared monitors and efficiency of the proposed scheduler have not been evaluated.

5. Confusions
Why are monitors more structured compared to semaphores?
What sort of subtle bugs are introduced due to cooperative scheduling?
Why is execution time of FORK+JOIN so high when the authors claim that process creation is moderate?

1. Summary
This paper discusses how to provide concurrency within threads with synchronization provided by monitors. This was achieved with preemptive scheduling of light-weight processes and monitors: need to do I/O, allow for multiprocessors, allow information hiding between modules, more structured locking and work out subtle issues appeared in its integration with Mesa. These were validated across diverse applications.
2. Problem
Due to large-sized and wide-varied applications, there was need to resolve program structure-unawareness in process, dynamic process and monitor creation, ambiguity in WAIT semantics, maintaining monitor-invariant in exceptions and IO, priority-based scheduling. As opposed to monitors, non-preemptive scheduling imposed restriction on: semantics across multi-processors, time-critical events, programming generality within critical sections and multiprogramming across page-faults while the semaphores exert less structuring discipline in concurrent programs.
3. Contributions
Dynamic creation was made possible with Mesa by invoking new process concurrently with its caller and establishing same communication semantics as procedure subject to strict type checking with no special declaration required. Solutions are provided to prevent deadlocks like avoiding recursive calls, partial ordering and breakage of monitors into smaller parts. WAIT semantics was properly defined with Notify signaling (timeout, abort or broadcast) and releasing the lock for waiting process; extra care was taken while executing internal (lock released) and external procedures (assuming lock being held). Invariant is made sure to be established when control leaves the monitor. Priority scheduling is ensured by associating each monitor with highest priority of process which never enters monitor so that priority of process entering monitor can be temporarily increased. Exceptions handling uses procedure-call process to control exception processing i.e. they either occur concurrently or are separate processes. Monitored record, used as protected monitor data was introduced to exercise fine control over addition and removal of shared data objects. Naked notify is introduced since devices cannot wait on monitor lock which causes interrupt handler to takeover atomic actions.
4. Evaluation
Authors split the implementation evenly across compiler, runtime and hardware; compiler recognizing syntactic constructs and performing static checks which was enriched by Mesa control structure primitives, wait-bound and compute-bound processes handled by runtime, hardware implementing procedure activation records, it’s scheduling and monitor entry/exit. Addition of monitor and its entry procedure code/data incur small storage cost compared to typical modules and procedures with the exception in FORK/JOIN. Similar behavior is observed in the cost of calling and returning from monitor entry procedure. With careful placement of monitors and processes, about a dozen distinct deadlocks are fixed. Complex structure of distributed database could be managed by single monitor and CV. A single process switch was made possible in the most critical path shared by asynchronous processes. UNWIND handler is necessary for entry procedure to maintain invariant but authors fail to evaluate the alternatives to restrict deadlock. They also fail to implicate the effects of calling procedure outside monitor module which ends up doing WAIT.
5. Confusion
How this model stand in case of preemptive multitasking-based systems?

Summary:
The paper describes the support of concurrent programming in Mesa with processes and monitors. While processes are the fundamental building blocks for expressing parallelism in Mesa, monitors are used to manage mutual exclusion between processes that share data.

Problem:
The existing structure of processes did not fit into the module facilities in Mesa. They also did not allow dynamic creation of processes. Existing proposals for monitors either had a fixed number of monitors that did not scale with data or ambiguous definitions of wait and exception handling inside a monitor forced the authors to clearly define the semantics of monitors and implement it in Mesa.

Contributions:
1) Process creation in Mesa is considered as an asynchronous procedure call where the newly created process runs in parallel with the caller process. Concurrency can be controlled by the calling process either by running it in parallel and joining on it or by detaching itself from the process making the newly called process a standalone one. By the way of design, the process semantics fits well into the module feature supported by mesa. Fundamentally, a new process could be created by calling a module procedure from the parent process with appropriate semantics.
2) Exception handling could be done throughout the calling hierarchy of the procedure/process starting from the block at which exception is handled. This clearly lays out the structure of the exception handling by putting the onus of exception handling.
3) Monitors in mesa are considered to be special modules, some/all procedures (called entry procedures) of which guarantee mutual exclusion amongst processes. The semantics of a wait inside an entry/internal procedure is well defined in that, the monitor lock is released before the the process waits on a condition variable. However, the lock is held while calling an external procedure. it is the application’s responsibility to avoid deadlocks in such scenarios.
4) Support has been provided to have concurrent accesses to procedures of different instances of the same monitor module.
5) I/O devices interact with the system and notify condition variables without holding the monitor lock. Wakeup-waiting conditions that ensue could be solved using the wakeup-waiting switch.
6) Mesa also provides a solution to the priority inversion problem with processes of different priorities contending for the same monitor lock.
7) Separate scheduling queues are maintained by the OS for ready processes, waiting processes and faulting processes.

Evaluation:
The paper evaluates the memory requirements of monitors and processes in terms of data overheads and code and compares it with the memory footprint of standard procedures and modules. The paper also evaluates the execution time overheads of process switch, wait and notify operations,etc. These seem to be plausible values. However, the fork/join call for a process creation/joining is 38 times slower than a procedure call. The authors have not reasoned out the overheads. This could actually be a deal breaker when it comes to using concurrent programming in mesa. The authors could have reported results from actual programs to compare the performance of such costly process creation over the baseline sequential execution. The authors could have run multiple instances of the same program together to measure the worst case monitor contention overheads.

Confusion:
Partial ordering on resources and how they avoid deadlocks.

1. Summary: This paper explains the implementation and design decisions taken while integrating Monitors in Mesa, the programming language of the Pilot Operating System. In the process, the authors enrich the Mesa language features by adding support for creating processes, synchronization, changing I/O handling etc.
2. Problem: The authors wanted to introduce concurrent programming facilities for their new OS to be able to allow resource sharing, parallel programming, and quite uniquely to replace interrupts. They surveyed the primitives available at that time, and selected Monitors as the way to go. They claim that despite a lot of research into this field, the problems related to actual implementation of Monitors were largely unresolved. These include nested monitor calls, definition of WAIT, handling exceptions, priority scheduling with monitors among others.
3. Contribution: The main contribution of the paper is perhaps the extensive implementation and design detail, that not only demonstrated a successful implementation in a real language, but also provides their motivation and the semantics of the language used. This would have definitely helped in implementing Monitors in other languages as well. Specifically, they explain that each process in Mesa is a procedure, and this easy semantics helps in having a dynamic number of processes in the system. To solve the problem of nested calls and provide a definition for wait, they introduce the notion of invariants. Each monitor maintains an invariant, that is always true unless a monitor procedure is being executed. The lock is released, if WAIT is in internal procedure, but not if WAIT is in outside monitor. To provide synchronization across multiple instances of an object, they provide monitored record. They also specify the exception handling by UNWIND, and clearly specify the need for an UNWIND handler for entry procedure, else the lock is never released. The simple implementation of condition variables is another contribution. They do this by modifying the semantics of NOTIFY to provide a hint rather than a guarantee. All this also helps to keep the verification rules of Mesa simple. The problem of priority inversion is solved by letting the monitor inherit the property of the highest priority process, and later making the process priority equal to that of the monitor. They also provide features of Naked NOTIFY to handle I/O devices.
4. Evaluation: The authors focused mostly on providing an implementation of Monitors in Mesa, and thus enough evaluation was not done. They were able to successfully solve the unresolved issues with Monitors, in some cases even providing optimizations like reducing unnecessary context switches in the system. They also provide few details like storage costs, and time taken for monitor modules, and other constructs like WAIT, NOTIFY etc. I would have liked to see more discussion of situations like deadlock, and race condition due to NOTIFY hints which they don’t handle.
5. Confusion: How are monitors compared to locks and condition variables? What is wake-up waiting switch that helps to solve race conditions in naked NOTIFY?

Summary
The paper describes the experiences designers had with designing a system that relies on light-weight processes and monitor facilities for all its concurrency needs. The paper also describes various subtle issues of implementing a LW process-with-monitors design in real life for a large system.

Problem
More and more applications started relying on concurrency to harness more performance. To address concurrency, one of the synchronization mechanism used is Monitors. However, monitors, often struggled to meet the real-world needs of a wide variety of large size applications. The existing implementations assumed a fixed set of processes at compile time, or a fixed number of monitors. WAIT call definition varied from implementation to implementation and hence lead to confusion w.r.t nested monitor calls. Moreover, there was no handling for timeouts, aborts, exceptions. An appropriate priority scheduling is also missing leading to priority inversion.

Contribution
The biggest contribution of this paper is to refine processes and monitors in the context of Mesa to allow concurrent programming. This is done by doing changes at Mesa compiler, runtime package and underlying machine level. There are three language constructs in Mesa - light weight processes, monitors and condition variables. Using fork/join, Mesa allows creating/deleting processes that can run concurrently as a special procedure along with its caller. Passing parameters and retrieving results is similar to calling a procedure. A monitor is an instance of a module - basic unit of global program structuring making clear what is being monitored. The language automatically acquires and releases lock. There are three types of procedures in a monitor - entry (acquires and release lock), internal (no locking required) and cant be called from outside the module, external (no locking done) but is externally callable. Mesa takes a different view of condition variables than what Hoare defines. Here, when one process establishes a condition for which some other process may be waiting, the process notifies the corresponding condition variable. This notify is regarded as a hint to a waiting process causing some process waiting on the condition to resume at some convenient future in time. Whenever the waiting process resumes, it will reacquire the monitor lock. This type of notification enables three ways to resume a waiting process - timeout, abort and broadcast. Notify is also used to communicate with I/O devices and is called Naked Notify as the device never holds the monitor locks. Process priority is handled by associating the priority of the highest priority process which enters the monitor with the monitor. Thus the process's priority increases temporarily to that of the monitor's priority whenever it enters a monitor.

Evaluation
The authors provide space(data and code) and time comparison of the costs of processes and monitors with other basic Mesa constructs like simple statements, procedures and modules. Compared to the basic constructs, processes and monitors do introduce an overhead in terms of space and time. However, it is hard to get the big picture based on these numbers about the total impact on the performance of the system. The authors do provide a good explanation of using the new constructs to develop Pilot (an OS), Violet (a distributed calendar system) and Gateway(an internetwork forwarder). Overall based on that description, it seems that concurrent programming has become easier and has helped in identifying deadlocks and fix them. However, they don't provide throughput/latency numbers to show a detailed evaluation of how things stand by using the new constructs.
As Mesa's definition of monitor/condition variable is different from Hoare's definition, a comparison between both of them would have helped in giving the right picture if the design choices are indeed correct or not.

Confusion
I want a discussion on hints vs. guarantees as hints can sometimes lead to starvation even though its simple to implement. Is Java's synchronized objects designed on the same lines as Mesa's monitors?

1. Summary
Lampson and Redell describe the implementation of Mesa, and their model for controlling concurrency through monitors in a real-time system. Mesa is a strongly typed, block structured programming language. It is also a scheduler for resources with one monitor per resource. They discuss priority scheduling, exception handling, and semantics of condition variables. This was developed while building Pilot operating system, in which they need programming constructs that provide efficient synchronization.
2. Problem
They discover the issues with a real-time system where the program structure should be modular to fit all processes, expose dynamic process and monitor creation and destruction, avoid deadlocks, handle exceptions, interact with scheduling of processes, including I/O in the framework of monitors and conditional variables.
3. Contributions
A monitor is the basic model for synchronized communication between processes that share data. This monitor contains shared protected data, some condition variables, and monitor procedures used to accessed shared data. At most one process is executing a monitor procedure at a time. If a process is executing a monitor procedure, other processes which call an entry procedure need to wait => mutual exclusion achieved with a cleaner model. With Mesa semantics, signal is just a hint, waking process must recheck the state and it is OK for the system to wake up a waiting thread at random point and then waking process (return from wait) must reacquire the lock. As opposed to Hoare semantic which requires to transfer lock implicitly that strains the scheduler to wake up the right thread. Clever idea to use broadcast: everyone checks for condition and the right one wakes up. Then they employ rules on maintaining an invariant when dealing with locks while leaving the monitor or waiting. Thus, monitors provide mutual exclusion and signaling, as well as abstraction & correctness at programming level.
They extend their work to cover exception handling, support for timeouts and aborts. Interestingly, hardware is asked to raise conditions instead of interrupts, using a naked NOTIFY to notify a condition variable to wake up a waiting process (interrupt handler). They also associate with each monitor the priority of the highest priority process which ever enters that monitor.
4. Evaluation
They show the implementation and evaluate local costs in storage and execution time which is better when compared with similar sequential constructs. Context switch is very fast here. And this simple procedure calls take only 30 ticks. But they only compare performance in storage and execution with basic Mesa constructs, not different constructs but same monitor schemed models like Hoare. Finally they show how Mesa programming model can be used to program a wide variety of real time applications like an operating system, a calendar system using replicated databases, and an internetwork gateway. And through this they show the issues of bugs/deadlocks and their possible solutions. Some more experiments that evaluate the scheduling using priorities could have shown possible overheads and starvations. Comparing the synchronization overheads between Mesa’s CV and semaphores or other techniques developed that time is essential, hence should have been covered. With the applications developed, they could have easily tested the real-time system behavior targeting concurrency, load, frequent IO etc.
5. Comments/Confusion
Wouldn’t the naked notify, not being protected by a monitor lock, cause a race condition between two or more waiting processes.

1. Summary
In this article the authors describe their experience in designing concurrent programming facilities in Mesa using monitors. The authors describe various problems which could arise when using monitors in real systems of any size and propose solutions to these problems. They present the details of how they build a concurrent operating system - Pilot and some applications running on this operating system using process and monitor mechanisms in Mesa.

2. Problem
The contemporary literature was rife with discussions on using monitors for concurrency, but when the authors wanted to implement concurrency mechanisms in Mesa to build a concurrent operating system which can run a variety of large application programs which make heavy use of concurrency they discovered that there were many issues still not resolved in the literature. Contemporary research did not provide solution to handling concurrency in programs structured as Mesa modules, it did not talk about dynamically creating monitors for dynamically created processes, nor did it pay much attention to implementing WAIT in nested monitor calls or handling exceptions and handling interactions between monitors.

3. Contributions
The main contribution coming from this work is a Monitor module. Monitor modules unify synchronization mechanisms, data sharing and the body of code which performs the data access. The monitor modules have special procedures - entry and internal procedures which execute with the monitor lock held and as long as calling these procedures in any order produces in any order produces meaningful results the programmer does not have to worry about adding extra synchronization. Another contribution is introduction of monitored record which represent objects which have their own monitor for serializing access to themselves. Naked notify is another idea coming out of this work, the mechanism uses a wakeup-waiting switch in a condition variable to prevent races which occur when notify event is sent without acquiring a monitor lock.

4. Evaluation
The authors evaluated their implementation of process and monitor mechanisms in Mesa by writing a full fledged operating system and some applications. Authors accept that there were two main areas where they faced annoying problems - lack of mutual exclusion in handling interrupts and interaction of concurrency and exception facilities. Authors believe that the subtle bugs may have been, to some extent, caused by illusion of mutual exclusion provided by implementing interrupt handlers as monitors, but they do not provide more details. The problems in exception handling are due to specific interaction of Mesa signals with processes and monitors like calling WAIT in a nested monitor call and when programmer fails to provide a UNWIND handler for monitor which releases the lock. The authors provide some profound and practical issues in implementing the monitors, but they could have provided more details on performance of their applications like the throughput achieved by the gateway and the number of concurrent streams the gateway can handle or how responsive is the calendar application is to user interactions.

5. Confusion
In Naked WAIT the authors talk about the wakeup-waiting switch for the condition variables. How does that work?

1. Summary
This paper discusses how Mesa supports concurrent programming with monitors and addresses several issues not resolved before.

2. Problem
Although monitors have been discussed widely in the literature and there exists an implementation, they can not be applied to real systems with a variety of large programs. The semantics of WAIT in nested monitor calls remain ambiguous; dynamic process creation and destruction is restrictive; and the integration of monitors with exceptions, scheduling and interrupts requires more work.

3. Contributions
Starting a new process is done by doing a concurrent call. All procedures can be run as the root procedure of a process without special declaration, and argument passing as well as result retrieving are the same. The child process can be joined or detached later.
Monitors are also implemented as a variation of an existing mechanism: modules. Monitor modules have three types of procedures, external, entry and internal. External procedures does not acquire the lock, entry procedures acquire it at the beginning, and internal procedures can only be called in entry procedures.
The lock is released on a call to WAIT, and is reacquired when the process reenters the monitor. This only applies to the innermost monitor in the case of nested monitor calls. As the caller is unable to tell whether a call will WAIT, it is not economic to establish its invariant and release the lock every time.
To achieve finer control and allow a collection of objects to share the same monitor procedure code, Mesa introduces monitored records, which are essentially data records with locks. By adding a LOCKS clause to the header of a monitor module, entry procedures accept a monitored record and use its lock.
NOTIFY is treated as a hint. The waiting process does not need to run immediately and the condition can be violated again before it runs. This simplifies scheduling and reasoning on predicates to wait on, and also makes it easy to introduce more hints including Timeout, Abort and Broadcast.
I/O Interrupts are handled with naked NOTIFY. Dedicated interrupt handling mechanism is no longer need.

4. Evaluation
The authors measured the space cost of basic Mesa constructs and time cost of basic operations. All of these looks efficient except FORK and JOIN. The authors defended by pointing out that these two operations are used less frequently, and frequency of use was one of the principle of design.
They also shared some experiences on how they built an operating system Pilot, a distributed calendar system Violet and an internetwork gateway with the concurrent programming facilities in Mesa. The structure of the programs and their use of monitors are mixed together, which makes this part hard to follow.

5. Confusion
It seems in their system the processor does a lot of work that a conventional OS does. What is the role of Pilot in this system?

1. Summary
The paper describes the process of adding monitors to the Mesa language, in order to allow for a better and easier concurrency programming.
2. Problem
There have been many published work on monitors before this paper, but when the authors actually tried to integrate monitors into the Mesa language, they ran into a number of issues and had to make some design choices. Because of the diversity of applications running on their systems, some of these issues were not addressed previously.
3. Contributions
They describe the concept of a process and what its properties are in this environment. For example, processes are first class values in Mesa and parameters and return values to/from a new process is exactly like procedures. They also have the option of detaching a process, so that the parent process need not wait for it to finish.
The authors add monitors to the Mesa language by defining it as a module, in order use the original benefits of modules. Each monitor could have private data as well as various procedure types: entry, internal, external. Through this design, it is more clear which procedures are a critical section and which data can be locked.
They also discuss their design of condition variables. Their mechanism is different from Hoare’s definition where exactly one waiting process is woken up and allowed to run. Here, all the waiting processes are woken up, and because of competition, they need to make sure the waiting condition is resolved after they wake up and go back into the monitor. This is the design that is used today.
They also discuss the priority inversion problem that could rise using monitors and priority scheduling, where a process with low priority needs to run to allow higher processes to continue execution. They solved this problem by associating a priority with each monitor to let processes run at that priority when they enter the monitor.
4. Evaluation
The authors do a performance evaluation for every construct in their design. They present both the space overhead as well as time. They present the overhead of calling a monitor procedure compared to a normal procedure.
However, this paper is not claiming to have better performance over other systems. They are claiming that they have better concurrency programming model that applications can take advantage of. As a result, the authors wrote three applications to use the Mesa language’s process and monitor designs. They explain that for the general-purpose operating system Pilot, even though the internal structure is complicated, carefully using monitors and processes led to fewer deadlock bugs. They also claim that after a deadlock was discovered, it was easy to find the bugs and fix them. Not sure how one would prove these claims, so I presume just mentioning the experience would be good enough to show that monitors make the concurrency programming model easier and safer.
5. Confusion
They claim that fork+join has high overhead because it was written in software and that the underlying machine could perform much better doing it. How could the machine make it faster?

1. Summary
This paper discusses using monitors to maintain concurrency. The monitors are written specifically in Mesa and takes advantage of the language's constructs. Most of the paper describes how monitors function, from supporting constructs required to the implementation itself. Finally, it talks about Pilot and Violet, an operating system and a database manager respectively that are built on Mesa & monitor principles.

2. Problem
The authors have an operating system called Pilot with specific requirements: local concurrent programming, global resource sharing, and replacing interrupts. It also has to support a large variety of applications that rely on concurrent programming. After looking at existing monitors and various IPC paradigms, they eventually settled on the Mesa-based monitor structure to synchronize data access.

3. Contributions
In their simplest form, monitors are “modules”, which consist of a collection of procedures, their shared private data, and sequential programming used to implement data abstraction. There are three types of procedures: entry (which are used to enter the procedure), internal (which can only be executed inside the module and can only execute with a monitor lock), and external (procedures that logically belong inside the module but don't need the lock). In general, it can be assumed that there is some “invariant” of the monitor that determines whether or not there is a process actively using the monitor. The number of points at which a monitor has to reestablish its variant can be minimized by only releasing the monitor locks on waits within the monitor but holding onto them in waits in other modules.

A lot of the Mesa language lends itself to their monitor construct. For instance:
- Processes and their creation in Mesa are cast as a special “procedure activation” that execute concurrently with their callers.
- Mesa has a rich exception handling facility and can control/debug them easily.
- NOTIFY statements in Mesa are regarded as hints to processes and cause execution of processes to occur “at some convenient future time.”
- Mesa also has concurrent programming facilities that allow natural parellelism in applications.

Their implementation is split fairly evenly amongst the compiler, runtime package, and machine.
1) compiler: syntactic constructs and implicit call generation.
2) runtime: less common operations such as process creation and destruction.
3) monitor: commonly used features such as process scheduling and monitor entry/exit.
The overall effect is a layering with monitors/scheduling at the bottom and process creation/deletion at top.

4. Evaluation
Their main evaluation is a comparison of processes and monitors to other Mesa constructs such as statements, procedures, and modules. Each operation is measured in the form of time units called “ticks”. In terms of cost from highest to lowest, it goes FORK+JOIN, process switch, monitor procedures, call and return, wait/notify. It doesn't really compare Mesa monitors specifically with other monitor implementations, though, so it's hard to evaluate whether or not these really improved on anything other than being written in Mesa. They also introduce a few other Mesa-based code such as the Pilot OS, the Violet database system, and gateways and how they use the Mesa monitor. No performance comparisons are done, though.

5. Confusion
I'm confused at the boundaries between the Mesa language, the monitor structure, and the Pilot operating system. It seems that the three are tied really closely together, but I don't know what exactly is just the monitor and what else is the support inherent in the OS/language.

1. summary
The paper explains the monitor module defined by access level and creation source, and it also addresses the primitives implemented in monitor which consists of how to control the lock, how to acquire the condition, how to schedule their turn.

2. Problem
The previous literatures has proposed many mechanism for monitors but none of them can be used to implement monitor for real use. This paper, therefore, adds more specific mechanism such as WAIT, NOTIFY, exception handling for real use.

3. Contributions
The main contribution in this paper is that monitor is implemented with explicit policy such as WAIT, priority scheduling, exception handling. Monitor addresses each procedure or process in terms of data access and the use of lock or condition variables. All the executions including file access need a lock to proceed if the accesses takes place in the monitor. In order to prevent a lock to be lost in case that the process held the lock is being abandoned, exception handler named UNWIND is called and executes restoring the monitor lock. NOTIFY is used to awaken the process waiting the lock.
A monitor module consists of entry, internal, external. Entry module can not be executed concurrently and internal module needs lock before executing it, lastly external module does not require to hold the lock even during processing it.

4. Evaluation
The storage cost for monitor, lock, conditions in Mesa module is small compared to typical module and procedure. In addition to this, performance is efficient aside from fork and join procedure. I think it is useful way dividing evaluation results into separate items to explain how it is useful while they didn’t explain the reason why there are additional ticks in monitor.

5. Confusion
Which one is more attractive to use in shared memory system, Pthread or monitor? and why?
What is the implicit information of NOTIFY to awaken the process waiting the lock?