CS 736 Reviews - Spring 2015

Summary:

It describes a multiprogramming system which was built by developing abstractions for processor, memory and I/O. Each of these abstractions are represented by a process that runs at some level in the hierarchy. The lower the level, higher is its priority. And these processes are scheduled in the processor according to some priority rule.

Problem/ Goal

The goal as specified by the author is to build a multiprogramming system with the objectives:

a) Reduction of turn-around time for programs of short duration. i.e. Using interrupts and hence preemption to allow the execution of interactive processes.

b) Economic use of peripheral devices . i.e., Each peripheral device providing services to multiple processes in a time-shared manner.

c) Automatic control of backing store combined with economic use of central processor. i.e. This is related to the concept of a level of indirection from segments to pages and time-sharing of CPU, respectively.

Contributions:

The main contributions were:

a) Developing an abstraction for memory: It decoupled the processes' logical memory from the physical memory by providing a mapping between them through the concept of segments and pages. Segments are equal-sized chunks of logical memory whereas pages are equal-sized chunks of physical memory in either the primary or secondary storage.

b) Developing an abstraction for processor: It introduced the concept of preemption through timer interrupts and hence the multiplexing of "sequential processes' onto the same processor. It also introduced the concept of mutual synchronization between processes for their harmonious cooperation through the use of semaphores.

c) Building a system by placing the various abstractions on a priority-based hierarchical structure.
Level 0 deals with scheduling and interrupts.
Level 1 with Memory Management. Level 2 with Console I/O. Level 3 deals with Other I/O.

Evaluation:

Though the author has not provided any concrete data regarding evaluation, he has mentioned that he has proved the correctness of the harmonious cooperation of processes by using mathematical induction. He has also mentioned that due to the hierarchical structure of the system a small set of test-cases could be used to do an almost exhaustive testing of the system.

Confusion:

Is it usual to prove the logical correctness of a system as was done by the author? Do we prove the correctness of systems that are being developed today?

1. Summary
Dijkstra, in this paper has described the design principles and philosophies involved in the structuring of ’THE’ multiprogramming system, by providing independent abstractions for the sequential processes and organizing them into different hierarchies of the system. The paper also accounts, on how the hierarchal structure helped to prove the logical soundness of the system a priori and verify the implementation for correctness.

2. Problem
The main goal was to develop a refined multiprogramming system, by smoothly processing a continuous flow of many user programs. However, the other objectives being to build a multiprogramming system, which has - a) Good turn-around time (response time), b) Economic and efficient usage of peripherals, c) Efficient use of storage and CPU, d) Generality of the system for many applications and e) Multi-access system, not being a design goal. Although, not explicitly mentioned, the author has also stressed performing a thorough exhaustive testing of the system for functional correctness as his goal.

3. Contributions
Some of the design lessons and principles have been listed out as a progress report for system designers. Deciding the pathology of the system at an early stage, giving enough thought on the debugging infrastructure and previous design experience alongside thorough testing have been enumerated. The abstraction and distinction of memory units into core pages and drum pages is provided, with information units called ’segments’ residing in one of these pages. Random allocation of pages is supported.
Each user program in the system is regarded as a sequential process. Functional correctness is given more importance than the actual speed of the process. The design principle - “delaying a process temporarily can never be harmful to the internal logic of the delayed process” is the core idea of multiprogramming.
The system hierarchy is presented as a 6 layer one with each layer corresponding to a sequential process and its control. Level 0 being the bottom one, where each process gets the CPU to run and is timer interrupted by a real-time clock. Level 1 has segment controller abstraction where, the higher level processes use this level to communicate to core and drum pages using segments. Level 2 has message interpreter which is responsible for conversation between the operator and console teleprinter. The allocation of keyboard and printer is done here and above this level an illusion that each process gets its private conversational console is created. At level 3, another abstraction with system I/O is created which is responsible for buffering input streams and unbuffering output streams. Level 4 has independent user programs and level 5 is the operator/user.
To achieve harmonious co-operation among the sequential processes, mutual exclusion and private semaphores are used. And a restriction that lower level processes cannot generate tasks for upper level processes is imposed to avoid situations of circularity and deadly embrace.

4. Evaluation
The paper does not explicitly provide empirical data or statistics as a whole to show the results of system responsiveness or CPU/memory usage or application generality. However, it is presented more of a design progress report with their evaluation methodology inbuilt into there testing infrastructure. An elaborate report on how design for testability is done, by having a test wrapper at each level of system hierarchy making sure that it reaches all relevant states and corner cases is provided. But, some evaluation results should have been provided to support their claims.

5. Confusion
How does indirect addressing mechanism suits for stack implementation? With good system response time being the main goal, what is the scheduling policy used to achieve that? What does actually a test shot comprise of. Did not understand what a ’steam’ method is? Can this multiprogramming system be modified based based on user requirements and if yes how easy is that? Also curios about whether this design principle of hierarchal structure acted as precursor for modern system softwares and if yes how?

Summary:

This paper is a progress report of the THE multiprogramming system which explains how a layered system structure could be used to provide increasing levels of abstraction. This paper also describes Dijkstra's philosophy with regards to system design.

Problem:

The designers were trying to create a system which allowed multiple independent tasks to be executed concurrently. Their design challenges were synchronizing multiple independent sequential processes while ensuring their correctness.

Contributions:

The major contribution of this paper is the hierarchical design which was used to provide hardware abstractions. With this structure, the designers were able to theoretically prove the logical correctness of their system while also ensuring a layered design which was easy to verify. By having these levels only generating tasks for processes at lower levels, they were able to avoid circular dependencies.

Their memory design is also interesting in the sense that they took the concept of pages from an earlier system and used smaller segments of these pages as the memory granularity at which processes operate. This allowed their system to add another level of indirection to their memory system while allowing for more segments than were physically possible. It reads like an early version of a virtual memory system.

This paper also introduces the use of semaphores as a means to synchronize processes and explains how they can be used to create mutex locks as well as condition variables.

Evaluation:

As this paper is a progress report, complete system testing wasn't completed at the time it was written. However, the designers (or Dijkstra at least) had misgivings with debugging complex software systems and exercised caution in the logical design and implementation of THE. They were able to prove the logical correctness of the system by design of the system hierarchy. In addition, this hierarchical system allowed them to build and test the system level by level.

However, I'm not sure if their system would have met all of their goals, specifically reducing the turn around time for short duration programs. By focusing on the correctness of the system, it seems like this goal was somewhat ignored. The progress report doesn't really explain process scheduling but focuses more on the synchronization of sequential processes which perform independent tasks. However, this is a progress report and this might have been addressed in subsequent documentation.

Confusion:

One of the goals for THE is an indirect addressing mechanism which is suited to stack implementation. I understand that they used the concepts of segments and pages to implement indirect addressing but I can't reason how this memory system is particularly suited to be used with a stack.

1. Summary
This paper presents a progress report and details on developing a multiprogramming system. A set of mutually synchronized sequential processes are responsible for the functioning of the system. These are layered in a hierarchy of 6 levels in each of which one or more abstractions have been implemented. The author emphasizes that this layered approach has simplified development and testing efforts. The Appendix describes semaphores, a synchronization mechanism developed in the system and a proof of the author's claim that a multiprogramming system can be designed in such a way that its logical correctness can be proved a priori.

2. Problem
The primary goal of the system proposed in this paper was to process multiple user programs smoothly as a service to the University.
The "THE" Multiprogramming System was built with the following set of objectives:
1) quick turnaround time for programs that run for short duration
2) efficient use of peripheral devices
3) automatic control of backing store with economic use of the processor
4) multiple applications that require a general purpose computer must be able to use the system economically
5) not intended to be a multiaccess (multiuser) system

3. Contributions
This paper has made some major contributions to the field of Operating Systems in the areas of distributed processing and system design.
It introduces the concept of today's virtual memory and paging with the description of Storage Allocation in this system. The author introduces 2 terminologies: pages (for memory units) and segments (for information units). With the use of segment identifiers and segment variables, the author seems to have overcome the disadvantages of the classical Von Neumann machine that existed at that time where information was identified by the address of the memory location containing it.
This paper also introduces a process synchronization mechanism called semaphores with the description of Processor Allocation in this system. The system is designed in terms of abstract sequential processes each having a well-defined functionality. Their harmonious cooperation is regulated by explicit synchronization statements which might delay the process but will not affect the logic of these processes.
Dijkstra and his group has made some key contributions to the art of system design through this paper. The layered architecture of the system in which higher layers only depend on lower layers reduced the efforts required to test the system exhaustively. A complete set of test cases can be written for each layer before adding a portion of another layer making it easier to identify all the "relevant states" of the system. This strategy is followed in Software Engineering even today.
The author cites having previous experience with software dealing with real-time interrupts and the difficulty of debugging the nasty bugs it can introduce. With careful attention paid during the design, the author states that it is possible to design a multiprogramming system in such a way that its logical correctness can be proved a priori. The appendix also presents a proof for this. This philosophy of design to make testing easier is relevant even today after so many years.

4. Evaluation
The paper is presented as a progress report with some lighthearted elements in it. There is no empirical evaluation of the system built or its comparison with other systems. The systems seems to meet the objectives stated in the introduction. The author mentions that at the time of writing the paper, the testing was not yet completed, but was confident the resulting system is guaranteed to be flawless because of their design principles.

5. Confusion
I am curious to know what is priority rule used in level 0 responsible for processor allocation.
Why do the number of segment identifiers have to be larger than the total number of pages in primary and secondary store?
In the Design Experience section, the author mentions "steam method" used while developing the system but does not elaborate on it.

1. Summary
This paper introduces Dijkstra’s exploration and experience in designing the “THE” multiprogramming system. It reviews mistakes and progress during design and focuses on the system structure and experience of designing the system in 6 layers.

2. Problem
In the goal to process continuous flows of user programs smoothly, problems include,
- reduce turn-around time for programs of short durations

- use peripheral devices economically

- control backing store and central processor automatically and economically

- use the machine economically with only general purpose computers

3. Contributions
- Distinct between memory units(“pages”) and corresponding information units(“segment”). Created independent identification mechanism for segments, with which the drum page with the minimum latency is selected and get rid of the drum allocation problem.

- Arrange the whole system as a society of sequential processes and progress them accordingly. This helps to make sequential processes execute in different speed rate and easier to switch between each other.

- Build the system in a strict hierarchy.
Level 0: allocate process, achieve quick response;
level 1: segment controller, further abstract storage pages;
level 2: message interpreter, taking care of conversation between operator and higher level processes, abstract that each process has its private conversational console;
level 3: buffering inputs and unbuffering outputs;
level 4: independent user programs;
level 5: the operator

- Experience in design
Reasoning helps meet requirements with mutually synchronization; traditional approaches are also needed; doing early test of components and the consequence shows the hierarchical design of system is useful.

4. Evaluation
This is a paper that simply illustrates the experience and general design of the system. Though it provides very helpful concepts and advice, in my opinion, it is really hard to use this as a guide of system design.

5. Confusion
- It specially notes that the system is not a multiaccess one, as there is no common data base for users to communicate with each other. How do they achieve communication if they need to? Or does it mean there is no communication between users at all in a multiprogramming system?
- Not quite understand the “core page” and “drum page”.

Summary
This paper describes the design and development of 'THE' Multiprogramming system, where all the activities were divided into a hierarchy of mutually cooperating sequential processes. It also explains as to how this hierarchical design permits a rigorous verification of the soundness and correctness of the system .
ProblemThe multiprogramming system was mainly designed to 1)process a continuous flow of user programs 2)reduce the turn-around time for programs of short duration 3)effective use of resources such as cpu 4)allow a single computer to be used for multiple tasks
Contribution
The system design shows a transition from batch operating systems towards multiprocessing ones. "Delaying a process temporarily can never be harmful to the interior logic of the process delayed" is the central idea of multiprocessing. It also introduces an approach where, information units are addressed using 'segments' rather than the address of the memory location and thereby overcome the drum allocation problem. The hierarchical system of processes was another significant contribution. Level 0 dealt with process allocation, level 1 dealt with memory virtualisation,level 2 dealt with inter process communication, console management (message interpreter), level 3 dealt abstraction of peripheral devices, level 4 application and level 5: user/operator. Each layer abstracts away some underlying details and presents this abstraction to the layer above so that at layer 4 where programs run, the programs see only a single system where they have total access. The paper also describes the use of an incremental testing scheme which allows for more efficient testing, as each layer from bottom up are verified before proceeding to the next layer.
Evaluation
The author states that they had put major intellectual effort to develop testing programs that would formulate all relevant states possible, but no performance evaluation figures, except bug density were stated.
Confusion
The author states that "indirect addressing mechanism was very well suited for stack implementation". What is the logic behind that statement? The details of the proposed scheduler at level 0 were not clear.

Summary
In this paper, Dijkstra presents the ‘THE’ multiprogramming system that was a single-user multiprocessor operating system. The hierarchical structure of the system allowed for abstraction of processes, memory and devices. Some early concepts and fundamentals of OS design mentioned in here are very much part of OSes today.

Problem
The primary objective of building a multiprogramming system was to maximize utilization of resources, reduce turn-around times for programs of short-duration and also process lighter workloads economically. The idea was to build a system that failed under no circumstances. The author claims that by rigorously proving the logical soundness and correctness and performing an exhaustive testing, a flawless system could be achieved.

Contributions
1.An early form of paging and memory management was introduced using the concept of segments. Segments can be mapped to core (in-memory) or drum (physical Hard disk) pages. Page swapping and page miss were also tackled in THE system.

2.Dijkstra proposed “delaying a process temporarily can never be harmful to the interior logic of the process delayed”. Whole system was viewed as group of sequential processes and context-switch among the processes was induced by timed interrupts.

3.Semaphores enabled mutual synchronization of parallel sequential processes. System resources were allocated among processes exclusively using semaphores.

4.The hierarchical system presented in 6 layers (0-5). The higher layers only see the abstraction presented to them by the layers below. For ex. the ‘message interpreter’ (console) at level 2 is above level 1 (abstracts memory management) which in turn is above level 0 (abstracts scheduling).

Evaluation
The need for testing THE system has been emphasized in the paper but no proper testing methodology has been explained per se. Except that, a layer by layer testing was done before proceeding to the next layer in system hierarchy. This approach turned out to be full proof. Overall in this paper, an uber conceptual idea of a multiprogramming system has been detailed.

Confusion
The author mentions in his objectives of creating a multiprogramming system – “automatic control of backing store to be combined with economic use of the central processor”. What does this mean? And how has this goal been achieved?

Summary:

Edsger Dijkstra in the paper, "The Structure of the "THE" multiprogramming system" describes the design, implementation and verification of a multiprogramming system. The key new ideas introduced in the paper are memory virtualization, a 5-level structure for the OS and semaphores for providing multiprogramming support. It also provides an interesting discussion on how a reasoning could be laid about the correctness of the system, by carefully eliminating bugs and testing at every level of implementation.

Problem:

The main problem addressed in the paper is of processing of continuous flow of user programs in an efficient way. The specific objectives which the author tries to achieve are to to reduce turn-around time for short programs and to provide efficient use of memory and CPU. It is important to note that THE multiprogramming system was not essentially designed as a multi-user operating system, i.e. multiple users could not use the system concurrently.

Contributions:

The main contributions from the paper are the layered OS approach, concept of "segments", multiprogramming support using semaphores and also a technique to reason about correctness of system design. Below, I expand on each of these contributions briefly:

1. Layered OS: The layered OS approach provide abstraction of the hardware resources and the higher layers have to access lower layers for resources proceeding in a top-down approach. This mechanism provides the ability to test/verify the system from layer 0 up to layer 5 and the feasibility to implement it from the core to the top.

Level 0 provides processor virtualization primarily containing processor allocation and scheduling of processes.
Level 1 provides memory virtualization and management and higher levels access memory in terms of segments provided at this level. Segments are mapped to physical addresses.
Level 2 has a "message interpreter" providing console I/O.
Level 3 provides abstraction for the I/O devices of the system.
Level 4 is the user programs and level 5 is the user. .

2. Virtual memory : THE multiprogramming system was probably one of the first to give an idea of memory virtualization, so that programmers need not specify the physical address in the drum for accessing memory. This is an important contribution of this paper.

3. Providing multiprogramming support: The paper describes how semaphores can be used as condition variables or mutexes to provide mutual exclusion which helps towards achieving the multiprogramming goal.

4. System Design by way of eliminating bugs: An important contribution of this paper is also the fact that the correctness of a system can be proved a priori and also how we can reduce the need for exhaustive testing by careful implementation and design policy.

Evaluation:

To prove correctness, the author describes the design experience which tends to show that a combination of layered approach and removing bugs at every stage prevents the need of an exhaustive testing of the overall system, still guaranteeing that the system works as desired. The author believes that an important contribution is the intellectual effort required to convince oneself that an important test case has not been left out.

As such, the paper does not provide any quantitative evaluations comparing it with other implementations (rightly so, since this was one of the first such implementations) or providing a mathematical rigor towards proving that the design leads to a system as desired. The paper aimed at reducing turnaround time, and it would have been interesting to see statistics on how this was achieved.

Confusion:
How do segments map to physical memory? Is deadlock prevention explicitly by the user or are there ways in which the system can handle deadlocks on its own?

A thought provoking question: Do modern systems take a cue from the design of this layered system? If yes, what are the layers used and how do they integrate and perform as compared to the 5 layer approach suggested by Dijkstra.

The Structure of the “THE”-Multiprogramming System
Summary:

In this paper, the author describes a multiprogramming system in which the activities were divided across a hierarchy of sequential processes. The paper describes one of the early engineering process behind the development of a multiprogramming operating system. More importantly, the paper describes one of the earliest attempts in abstraction of resources. Also, to synchronize the processes, the concept of semaphores were used.

This paper was published at a time when computers were built to do batch processing. The main goal revolved around developing an operating system “to process smoothly a continuous flow of user programs”. Specifically, the author wanted to reduce the turn-around time of programs of short duration and economically use the peripheral devices. Also, the system tried to combine the economic use of the processor with control of the backing store.

Storage Allocation:
Separating the actual memory from memory units in the form of pages and segments provided greater flexibility in utilizing the drum memory and solved the drum allocation problem.

System hierarchy:
The use of a hierarchical model helped in abstraction and avoiding circular waits as processes in one level could wait only for processes in lower levels. By following a hierarchy, the processor abstraction was achieved by using a process that is responsible for the allocation at level 0. At level 1, the segment controller provided an abstraction for drum memory and processes at higher levels referred only to the segments. At level 2, the abstraction of the console take place using the message interpreter process. At level 3 the abstraction of peripheral devices takes place. The higher levels are occupied by user programs and the operator.

Synchronizing primitives:
In my opinion, the greatest contribution is the idea of a semaphore for synchronizing between processes. Switching between processes became easy because if a process is switched when it was executing a critical section, the other processes would be going to sleep and mutual exclusion was obtained.

Since the paper is more about a survey of the system the author was designing, there were no measurement of performance nor any comparisons made against another system. The author does say that the system was rigorously tested at each level with all the “relevant states”. We can infer that when level 3 was tested, user programs should have been used and processes should have run simultaneously.

The author says that the segment identifier gives fast access to a segment variable in core which identifies whether a segment is empty or not. How were they practically implemented?

1. Summary
This paper describes the design of a new multi-programming effort led by the famed Dijkstra at Eindhoven University. It details the system structure (as used by processes) through three main concepts: storage allocation, processor allocation, and system hierarchy.
2. Problem
Dijkstra and his group specifically wished to contribute to the art of system design, but had a small team of limited hours. Due to these constraints and limited experience, they had to work intelligently to develop a set of guiding principles in their effort. With these issues in mind, the goal was to create an operating system with typical, expected results. Short programs should have quick turn-around time, there should be economic use of peripheral devices, and the storage/memory interface should be efficient and simple.
3. Contributions
There were several key contributions to this paper: I will detail 3 specifically.
1. Dijsktra introduced a segment controller, which allowed for the introduction of virtual/physical memory and sending pages out/in from the disk. More advanced versions of this method are still used today.
2. The hierarchical system of processes was an enormous contribution. A base level dealt with process allocation, a level higher dealt with memory virtualization, etc. At each level, details were abstracted away via lower levels. This simplified the design, implementation, and testing phase of the OS.
3. Perhaps the largest contribution came from Dijkstra's semaphores. These could be used both as a mutex or as condition variables. Both cases are still used today.
4. Evaluation
In several locations in the paper, Dijkstra seems to express dissatisfaction with the group's current progress, and seems almost underwhelmed by the contributions. However, he mentions that they have in fact made a major contribution to system design: they were able to design a refined multiprogramming system whose logical soundness can be proved. They do not explain in detail how this was done - I would like to see more on this detail.
The contributions mentioned above also show just how effective this paper has been. The use of semaphores to create locks is still taught today, and semaphores are also still used as condition variables. The use of a wait list (in which one process is woken up as a result of a conditional semaphore) is also still done. In this sense, the paper was a resounding success.

5. Confusion
When reading the paper, I had two main questions:
1. In the last section, there is mention of special precautions that must be taken to ensure a segment moved from disk to memory will stay in memory until the relevant process actually accesses that segment. The details are not mentioned here. Is there any specific way to do this? (or is it just simple housekeeping details).
2. Private semaphores are described as unique to a specific process. But they are essentially used as condition variables in the example given. How exactly is this handled (so one process has access the private semaphores of another process in order to signal)? (Or do processes just use some shared semaphores in the OS)

1. Summary
This paper describes the design of a new multi-programming effort led by the famed Dijkstra at Eindhoven University. It details the system structure (as used by processes) through three main concepts: storage allocation, processor allocation, and system hierarchy.
2. Problem
Dijkstra and his group specifically wished to contribute to the art of system design, but had a small team of limited hours. Due to these constraints and limited experience, they had to work intelligently to develop a set of guiding principles in their effort. With these issues in mind, the goal was to create an operating system with typical, expected results. Short programs should have quick turn-around time, there should be economic use of peripheral devices, and the storage/memory interface should be efficient and simple.
3. Contributions
There were several key contributions to this paper: I will detail 3 specifically.
1. Dijsktra introduced a segment controller, which allowed for the introduction of virtual/physical memory and sending pages out/in from the disk. More advanced versions of this method are still used today.
2. The hierarchical system of processes was an enormous contribution. A base level dealt with process allocation, a level higher dealt with memory virtualization, etc. At each level, details were abstracted away via lower levels. This simplified the design, implementation, and testing phase of the OS.
3. Perhaps the largest contribution came from Dijkstra's semaphores. These could be used both as a mutex or as condition variables. Both cases are still used today.
4. Evaluation
In several locations in the paper, Dijkstra seems to express dissatisfaction with the group's current progress, and seems almost underwhelmed by the contributions. However, he mentions that they have in fact made a major contribution to system design: they were able to design a refined multiprogramming system whose logical soundness can be proved. They do not explain in detail how this was done - I would like to see more on this detail.
The contributions mentioned above also show just how effective this paper has been. The use of semaphores to create locks is still taught today, and semaphores are also still used as condition variables. The use of a wait list (in which one process is woken up as a result of a conditional semaphore) is also still done. In this sense, the paper was a resounding success.

5. Confusion
When reading the paper, I had two main questions:
1. In the last section, there is mention of special precautions that must be taken to ensure a segment moved from disk to memory will stay in memory until the relevant process actually accesses that segment. The details are not mentioned here. Is there any specific way to do this? (or is it just simple housekeeping details).
2. Private semaphores are described as unique to a specific process. But they are essentially used as condition variables in the example given. How exactly is this handled (so one process has access the private semaphores of another process in order to signal)? (Or do processes just use some shared semaphores in the OS)

Summary:

In this paper, the author Edsger W.Djikstra has described a hierarchical structuring of a multiprogramming system. He has also introduced the concept of explicit synchronization so that the logic correctness of multiple programs executed in the system would be maintained whether they are being executed on a single or a multiple processor machine.

Problem:

The author has tried to develop a structure for a multiprogramming system and has tried to prove the logical soundness of the design and correctness of its implementation.

Contributions:

The author has developed an abstraction for storage using segments which allows the flexibility for storing a huge file across non-contiguous drum pages or core pages. This helped in reducing the latency in the seek time by selecting an appropriate drum page which is closer.

The author considers all the processes to be executed in a certain sequential fashion even though multiple programs are in execution within the system. But, since one process might depend on another process and each process has its own speed of execution, Djikstra has introduced the concept of semaphore which is used to achieve the explicit synchronization between the different processes and thereby maintain the sequential order.

The author has also developed a hierarchical structure for the system with the user being at the top of the hierarchy followed by user programs, processes taking care of buffering, message interpreter, segment controller and process allocator. Each level in hierarchy is abstracted at the higher level. Eg., The inputs from the keyboard are read and interpreted by the message interpreter and passed on the the appropriate user process. The user process don’t have to worry about the interpretation. This hierarchical structure has also helped in the testing of the system by reducing the number of relevant state.

Evaluations:

The user claims the logical correctness of the system and that the testing of all the relevant states at each level in the hierarchy was done and found to be working as expected. Though one has to ponder if all possible states could be reproduced and tested. If testing was done by addition of extra peripherals. Also, the user hasn’t given any data or sufficient explanation if semaphore are enough for the process to communicate with each other and if it is ok to trust each process to change a global semaphore.

Confusions:

According to the author a process at a level can only create tasks for another process at a lower level. Does that mean one user program cannot assign tasks to another user program? So if a user program requires another user program to execute a task and give the result to it, do we need to spawn a new user process and communicate via semaphore?

The author says the system is not intended as a multiaccess system. What would be the problems if we try to use this structure for a multiaccess system?

Summary

The paper describes the structure of the multiprogramming system developed by Dijkstra and his team of researchers, while also expanding on the key benefits the structure brought about. In particular, the abstraction over the hardware such as the physical memory and the processor that was implemented is expanded upon in greater detail.

Problems

The problem to solve was to develop a multiprogramming system that can process a "continuous flow of user programs". Crucially, the system needed to cut down on processing time for small programs, handle the interactions with the secondary storage device on its own and ensure that it was time-efficient in the usage of the processor and other peripheral devices.

Contributions

One of the key contributions is the introduction of the concept of semaphores. The semaphore allowed processes to synchronize access to shared resources and thus enabled multiprogramming on the uniprocessor system. Furthermore, the introduction of the semaphore also allowed Djikstra to reason about the cooperation of the different processes and thus prove the correctness of the system.

Another of the main contributions of the paper is the introduction of an early form of virtual addressing. At the time the system was introduced, most other operating systems followed the von Neumann architecture where information was identified by the direct physical memory addressing on which it was residing. Dijkstra and his team however, introduced a distinction between information segments which are the address spaces the process sees and pages which are the actual physical addresses. This led to several key benefits such as being able to place information anywhere on the drum (since processes are not directly referring to a physical memory address) and thus easier process isolation.

The virtual addressing scheme developed was built upon to develop a hierarchical structure (with 5 levels) for the operating system. This was also another key contribution of the paper as Dijkstra showed how through this modular design, testing the correctness of the entire system was greatly simplified. Thus, through this work, Dijkstra also introduced sound software engineering principles to be followed in the development of later operating systems.

Evaluation

Dijkstra does not provide much quantitative evaluation of the system that they developed. Instead he shares with the reader, the thoughts of industrial software makers who feel that the system may not be flexible enough to handle different kinds of programs and also will not scale well. However, Dijkstra disagrees with this point of view, contending that in a larger system, the structuring is even more important.

Whatever evaluation Dijkstra provides of the system is mainly qualitative. He asserts the correctness of the system through mentioning his
testing of all the relevant states. However, it would have been more helpful if he had described the specific test cases in more detail.

Confusions

Dijkstra's explanation of the first major mistake is vague. It seems like he was describing a situation in which they paid too much attention to one part of the system, to the detriment of other parts. However, his use of metaphoric language makes it difficult to understand what exactly the issue was.

Another area of confusion was in the implementation of the segments. More specifically, in the mapping between the segments and the pages. From the sentence "a segment just fitting in a page", it seems there is a one-to-one correspondence between a segment and a page. However, Dijkstra later mentions that there are "the number of possible segment identifiers is much larger than the total number of pages in primary and secondary store" which seems to debunk the theory of the one-to-one correspondence.

Summary
The paper describes 'THE' multiprogramming system for a set of sequential processes. A six-level hierarchical system is proposed and semaphores are used for mutual synchronization. The proposed system has been verifed for logical soundness and correctness.

Problem
The multiporogramming system aims to lower the turnaround time for short-duration programs, effective and economic use of hardware and processor.

Contributions
1. Layered architecture for mutliprogramming system. All higher level layers depend on the lower layers.
- Level 0 corresponds to processor allocation (similar to scheduler) abstracting from all the layers above it.
- Level 1 corresponds to segment allocation (similar to paging) abstracting information in terms of segments for all the layers above it.
- Level 2 corresponds to message interpreter (similar to console).
- Level 3 corresponds to input stream buffering and output stream buffering.
- Level 4 and 5 correspond to independent user programs and operators respectively.

2. Explicit mutual synchronization of processes through 'semaphores'.

Evaluation
The paper focuses on the design and verification of the multiprogramming system and does not provide any evaluations to support the proposed hierarchical design.

Confusions
How is context switching done? How would the interprocess communication take place? It would be good to know how many processes can such a system could handle(aka scalability) other than just the correctness and testing aspect of the system.

The Structure of the "THE"-Multiprogramming
Edsger W. Dijkstra Technological University, Eindhoven, The Netherlands System

Summary:
The author describes a multiprogramming system and its structure. He explains his experience in designing, implementing and testing the system and the steps he took along the way that made it easier. Additionally the author describes a fundament of modern parallel computing, the semaphore.

Problem:
The author’s main goal is to design an operating system that allows several user’s tasks to run in parallel. Secondary to this was designing the system in such a way that it is provably correct (on some level) and simple to test.

Contributions:
The semaphore was an incredibly important logical contribution to the field at the time. Semaphores allow guarantees of mutual exclusion and synchronization between processes. In the simple case of a mutex, this is done by allow processes to acquire a “lock” and releasing it. While the lock is acquired, no other process may acquire a lock logically making any work done between “lock” and “release” mutually exclusive. The author also provides a notion of “segments” abstracting disk space and memory into an address space of segment identifiers. This allows the operating system more freedom when swapping memory to the disk as a page need not be swapped to its original location on the disk.
The author makes an important anecdote about the hierarchical design of the operating system. He argues that a layered approach to system design allows designers to come to logical conclusions about the correctness of the system beforehand, and also admits the system to being easily testable with a finite number of test programs.

Evaluation:
Some of the contributions are new to the field and not improvements which make it difficult to evaluate them in comparison to other approaches. On the other hand, throughout the paper, the author makes quite a few claims to the logical soundness of the system without really any evidence to that effect.

Confusion:
I did not quite understand the specifics of all the layers of the abstraction. I don’t quite get why the console keyboard is assigned its own layer, it seems like there could be some abstraction in a lower layer that would allow for some simplicity.

Summary:
In this paper, Dijkstra talks about the design, development and verification of an early multiprogramming system, which was based on layered approach and where the whole system is arranged as society of sequential process. The author explains the purpose of each layer that provides logical soundness to the system and facilitates level-wise testing. The paper also discusses semaphores that were used as synchronization primitives in multiprogramming system.

Problem:
The primary goal of this system was to smoothly process a continuous flow of user program as a service to the university. The goal was to reduce turnaround time for short duration processes, economic use of peripheral devices and to provide economic use of computing resources.

Contributions:
The author presents new operating system ideas:
1. Storage Allocation – concept of virtual memory, paging
2. Processor Allocation & Synchronization: Author describes system as a society of cooperating process and also discusses semaphores for providing explicit mutual synchronization
3. Introduces Layered Architecture:
a. Level 0: virtualization of CPU, timer interrupt, priority rule, abstracts number of shared processor
b. Level 1: Segment Controller – all higher levels identification of information takes place in terms of segments
c. Level 2: Message Interpreter
d. Level 3: I/O services – buffering of input streams and un-buffering of output streams
e. Level 4 & 5 – consist of user programs and operator
4. The author says it is possible to design a refined multiprogramming system in such an away that its logical soundness can be proved a priori and its implementation can admit exhaustive testing.
5. Paper also discusses importance of verification & testing at each level into design consideration so that relevant test cases can be performed at each stage of testing.

Evaluation:
The paper doesn’t talk much about the technical details about the design. Strong assertion about soundness of system and flawless system are made without any evaluation details or supporting details.

Confusion:
In processor allocation section – the mutual synchronization is possible because “delaying the progress of process temp” can never be harmful – are we considering processes trustworthy or am I missing something?

Summary:
The report introduces the structure of "THE"-Multiprogramming system and the synchronizing primitives used to do explicit mutual synchronization between parallel sequential processes.

Problem:
The primary goal for the system is to process smoothly a continuous flow of user programs as a service. The main objectives are to obtain a reduction of turn-around time for short durable programs, economic use of peripheral devices, automatic control of the backing store and the economic feasibility for inferior workloads.

Contribution:
(1) For the storage allocation, memory units and corresponding information units (segments) are strictly distinguished. Number of possible segment identification is much larger than the total number of pages in primary and secondary store. This method can reduce the latency for returning the drum pages and make drum allocation convenient.
(2) For the processor allocation, int a single sequential process, only the time succession of various states has a logical meaning. The system is a society of sequential processes and the harmonious cooperation is regulated by explicit mutual synchronization statements.
(3) The system is of a strict hierarchical structure. The responsibility for every level is that : level 0 processor allocation; level 1 segment control, level 2 message interpreter to take care of console keyboard, level 3 buffering inputstream and unbuffering of outputstream, level 4 independent-user programs and level 5 the operator.
(4) Propose synchronizing primitives (semaphore). P-operation and V-operation are used to access the semaphores.

Evaluation:
The paper is mainly a progress report so no much evaluation is given. But the author mentions that the hierarchical structure makes the testing valid and easier.

Confusion:
In my opinion, the relationship between segments and memory units seems like a virtual address to real address translation?

1. Summary
The design for a multiprocessing system is described where all activities take place in a number of sequential processes at different hierarchical levels, all moving at different rates and synchronized by semaphores.
2. Problem
The authors of the paper hoped to design a system to allow the coexistence of multiple jobs at one time, all moving at different rates and sharing compute resources. The actual CPU would be abstracted away along with the backing store.
3. Contributions
Dijkstra and co. designed a system with a general architecture as follows:

* "Segments" identified by a number are stored non-contiguously in memory, with a page table identifying where they are stored.

* "Mutual synchronization" statements, allowing sequential process to proceed at different rates and task switching between them, handled in the hierarchy shown:

Hierarchy:
level 0 - allocate processor time to tasks that can proceed in light of mutual synchronization using real time interrupts
level 1 - "segment controller" mapping segments to pages for everything above this level
level 2 - "message interpreter" input and output to processes are identified by the first sentence. To direct input to a certain process the name is literally typed in
level 3 - IO buffering
level 4 - Userlevel programs
level 5 - operator

Each level of the system was able to be tested separately because of the abstractions introduced by the lower levels

Mutual synchronization was accomplished by semaphores, special purpose integer variables that could have two operations performed on them: P and V. P decrements the value of the semaphore by one and if the resulting value is non-negative program operation can continue. V increments the value of the semaphore by one and if the resulting value of the semaphore is non-positive one of the processes that was stalled at P is allowed to continue.

Semaphores were used in two ways, mutual exclusion (only one process can be executing a block of code at a time) and private semaphores (the progress of one process can depend on the progress of others)
4. Evaluation
The "harmonious cooperation" of the system is shown in summary by a three part proof in the appendix, but no quantitative evaluation of the system is presented comparing the system to other solutions of the day. For example, the goal of "a reduction of turn-around time for programs of short duration" would have been a good one to evaluate, but it was not done.
5. Confusion
The author states that circularity is excluded because "processes can only generate tasks for processes at lower levels of the hierarchy". Is this negated by the ideas presented in the second paper of processes being able to request answers from other members of the same level in the hierarchy?

Summary:
The paper describes a hierarchical multi-programming system built as layers of abstractions that handle concurrent processes at five different levels. The reasoning behind the design and the testing methodology are emphasized to prove the correctness of the system, along with new ideas on memory paging and an appendix on the more technical details of process synchronization via semaphores.

Problem:
Taking on the problems of batch operating systems, the target of the multiprogramming system was to handle concurrent user processes in a way that was correct, reduced turnaround times for short processes and provided economic use of computing resources like the processor and peripheral devices.

Contributions:
1. The segment controller was an important redesign of automatic storage allocation as it is an early form of virtual and physical memory. The segment identifier, as a level of indirection between pages in core memory and drum storage, allows for the flexibility of allocating memory in discontiguous pages in storage for performance reasons.

2. New synchronization primitives called semaphores are introduced to manage mutual exclusion and synchronization between processes, which allows for preemptive scheduling of these processes at the lowest level.

3. A hierarchical design for managing the system’s resources(cpu,memory,peripherals) amongst the total set of sequential processes makes it easier to define all the relevant states at each level. This makes it possible to exhaustively test most cases of concurrency bugs by verifying and abstracting one layer at a time. We go from a*b*c… to a+b+c… test cases where a,b,c are the number of tests for the respective levels.

Evaluations:
Though Dijkstra’s reasoning in ensuring harmonious cooperation of the processes at every level is sound, it is not nearly enough to make the claim that “the system is guaranteed to be flawless”, even for him. Details on how he convinced himself of testing all the possible relevant states would have strengthened his claim. Secondly there was no mention of the scalability of such a system or if any problems would arise with that. Entertaining as his asides about software engineering practices were, it would have been more purposeful if he had generated figures on performance metrics, like turnaround time, that they had initially set out to achieve.

Confusions:
In the appendix on private semaphores, I did not understand how “the amount of coding and reasoning can be greatly reduced… by the introduction of the notion of an unstable situation...”? The result seems significant but i don’t understand how that was achieved.

Summary :

This paper gives us an overview of ‘THE’ multiprogramming system which aims at scheduling processes parallely and uses the idea of segmentation of memory. The components of the system are divided into a set of sequential processes arranged in a hierarchical manner.

Problem :

The problem in question was to design a multiprogramming system which could process a continuous set of user programs in a manner that makes effective use of the processor and reduces turnaround time.

Contributions :

1. The system is divided into 4 major levels. The scheduling of processes happens at the lowermost level (level 0) thus abstracting the higher layers from dealing with any low level tasks of CPU allocation.
2. The storage on the drum and also the core is in the unit of pages and is accessed by the higher level layers in terms of segments using a segment identifier. The segment identifiers are mapped to the page which contains the segment. Due to this layer of virtual addressing, the segments from the core pages could be written to any of the free pages on the drum whichever is faster to write to.
3. Level 1 is the segment controller which deals with memory storage and retrieval. It gets the segment identifier from a higher layer and retrieves the page on which the segment is stored.
4. Level 2 is a message interpreter which reads the message of the operator to decide which process it needs to go to.
5. The placement of the message interpreter above the segment controller is a justified decision as the collection of messages that the user could use are stored on segments and it is required that the segments need to be accessed for interpreting these messages.
6. Level 3 is associated with the I/O and peripheral device streams with which the operator interacts and Level 4 is associated with user programs.
7. The hierarchical structure also proved useful to them as the testing of each layer could be done independently and higher layers could be tested using all possible relevant states from the lower layer in the hierarchy.
8. The co-operation amongst the sequential processes is achieved by using mutual explicit synchronization primitives such as semaphores.

Evaluation :

There isn’t any mention about the degree of multiprogramming that the system has been able to achieve. One of the objectives was to reduce the turn-around time for short duration programs but there aren’t any evaluation metrics concerning this.

Confusions :

The processor allocation is said to use a priority rule to achieve quick response. It is not clear as to how it manages the priority of processes. The paper mainly dealt with multiprogramming but there is no mention as to how process switching is handled.

1. Summary

This paper describes the design and verification of the ‘THE’ multiprocessor system. The system is built around the harmonious cooperation of sequential processes. The system is organized in layers, which makes it feasible to achieve logical soundness through rigorous testing. The paper also presents the Semaphore as a synchronization primitive for processes.

2. Problem

The primary goal of this system was to run user programs in the University, so it does not have lofty quantitative goals. However, the designers seek to build a system whose logical soundness can be proven apriori and whose implementation can be rigorously tested before deployment.

3. Contributions

In my opinion, the seminal contribution of this paper is its philosophy of building layered systems where upper layers use the abstractions of the lower layer. Today, this approach is taken as common sense, but I’m sure it was not so back then. The lowest level consists of the scheduler which allocates the CPU to different processes and services the timer interrupt. For memory, the paper introduces a level of indirection between the storage address & the information stored in that location through the idea of the ‘segment’. I think segment is a simple form of virtual addressing, in which the program address is translated into a segment ID, which indexes into a table for getting the storage address. This indirection gives flexibility for allocation of pages. Segment controller is implemented as Level 1. Level 2 and level 3 are used for virtualizing the console & peripherals respectively. The physical resources are time-shared across processes above them. User processes operate at level 4. Such layering simplifies the design, as upper levels can use simplified abstractions, plus it greatly reduces the verification scope for each level. The system architecture tries to prevent many bugs by construction instead of expending effort on debugging them later. Synchronization across sequential processes is achieved using the Semaphore. Semaphores are capable of providing mutual exclusion and conditional communication.

4. Evaluation

Being more of a progress report, this paper does not present any empirical evaluation of the system. The author emphasizes that the design & verification time was reduced thanks to their layered design.

5. Confusions

On the last page, the author claims that harmonious cooperation across processes is guaranteed as a single process can never generated infinite tasks for other processes. This paragraph is not clear to me. Similarly, how are deadlocks ‘impossible’ in this system?
Lastly, the author refers to something called ‘steam method’ which was feasible in THE system. What is this?

1. Summary
In the paper "The Structure of THE - Multiprogramming system", presented as a progress report on the multi-programming effort at Technological University in Eindhoven, the author presents the key idea of representing a multi-programming system as a hierarchy of mutually co-operating sequential processes. He further explains how a layered approach to implementing the sequential processes not only provides a clear abstraction of the underlying layer but also allows level-by-level rigorous verification by which a good number of test cases can be covered.

2. Problem
The main focus of the system was to process continuous flow of user programs with:
- Reduction of turnaround time for short programs unlike the traditional batch systems
- Economic use of peripheral devices
- Automatic control of the core and drum memory
- Feasibility to use the machine for lower workloads which do not require high capacity or processing power

3. Contributions
Storage Allocation:
- Distinguishes between information units (segments) and memory units (pages) clearly and introduces a primitive form of memory segmentation. Instead of programmers accessing information using the actual physical addresses on the drum memory, the system provides a mechanism of virtual addressing.
- Flexibility to dump a segment residing in a core page to any segment in any drum page helps the system to exploit the latency delay and provide a multiprogramming environment.

Processor Allocation:
- View the system as co-operation among multiple sequential processes where the progress of any sequential process across different logical states is important than the actual speed of the process.
- Provide mutual synchronization and communication amongst these sequential processes through synchronization primitives (semaphores)
- Semaphores can be used to achieve mutual exclusion to a critical section and private semaphores (owned by a process) can be thought of as condition variables

System Hierarchy:
Level 0:
- Responsible for process scheduling (analogous to modern scheduling)
- Abstracts the processor
- Introduces the concepts of real-time clock based hardware interrupts to prevent processes from monopolizing the system and context switching to provide the illusion that the number of cooperating sequential processes is independent of the available processors
Level 1 (segment controller):
- Responsible for segment allocation (analogous to modern disk and memory management)
- Abstracts the physical pages of memory
Level 2(message interpreter):
- dealt with communication between the operating system and the console (analogous to modern IO management)
- abstracts the console
- If the message interpreter was not above the segment controller, there would be a heavy demand on the core storage to store the conversation between the processes
Level 3:
- Responsible for device I/O - buffering of input streams and unbuffering of output streams (Similar to modern device drivers)
- Peripherals are seen as logical communication units
Level 4:
- Independent user programs
Level 5:
- User/operator

4. Evaluation
The author does not mention about any explicit evaluation of the system. However, he makes an ambitious claim that the resulting system is guaranteed to be flawless.

5. Confusions
- What was the priority based rule used to achieve quick response from the system?
- Was any bench marking done on the system once it was completed, in his later papers?

Summary: The author of this paper shared their experience building a multiprogramming system including hierarchical processes, pages and segments, synchronization primitives, and the concept of device-as-a-process.

Problem: Building a general purpose computing system has many challenges.
1. Should be able to manage and execute multiple jobs at the same time.
2. Should be economical use of hardware.
3. Should be as reliable as possible.
4. Should be maintainable; that is, easy to locate and fix bugs.

Contributions:
1. Physical storage devices are divided into pages, and information storing on that is divided into segments. Segments will be swapped out when needed. Today the term "page" is more like the concept of segments in this paper.
2. Making each peripheral device a process. For example, the message interpreter process is associated with the keyboard and is responsible for receiving keyboard inputs. This is more like what we call a device driver today.
3. Processes are hierarchical. If we use today's terms, level 0 is a process scheduler; level 1 is a page manager responsible for swapping in and out segments; level 2 handles keyboard inputs; level 3 consists of processes of other input and output peripherals; level 4 includes all user programs; and level 5 is the operator. By making the processes hierarchical, the system becomes simple to implement and easy to verify.
4. Semaphore as a synchronization primitive, and using semaphores to implement mutex.
5. Lots of philosophies. Being as ambitious as possible when you start. Being as careful as possible when programming. Testing systems piece by piece (testing only one level at a time). Hire full-times, hire people with advanced degrees.

Evaluation:
The author did not explicitly evaluate their system, but implied that they were satisfied with it by stating two "happy consequences".

Confusions:
1. What is the harmonious cooperation?
2. The author claimed their system was "guaranteed to be flawless". Was it just a hope of the author or something that they can mathematically prove?