How to design and implement small time‐sharing systems using concurrent pascal

This is a personal history of the early development of the monitor concept and its implementation in the programming language Concurrent Pascal. The paper explains how monitors evolved from the ideas of Dahl, Dijkstra, Hoare, and the author (1971-73). At Caltech the author and his students developed and implemented Concurrent Pascal and used it to write several model operating systems (1974-75). A portable implementation of Concurrent Pascal was widely distributed and used for system design (1976-90). The monitor paradigm was also disseminated in survey papers and text books. The author ends the story by expressing his own mixed feelings about monitors and Concurrent Pascal.

Concurrent Pascal as a simulation language

The paper describes a new programming language for structured programming of computer operating systems. It extends the sequential programming language Pascal with concurrent programming tools called processes and monitors. Section I explains these concepts informally by means of pictures illustrating a hierarchical design of a simple spooling system. Section II uses the same example to introduce the language notation. The main contribution of Concurrent Pascal is to extend the monitor concept with an explicit hierarchy Of access' rights to shared data structures that can be stated in the program text and checked by a compiler.

This is a description of the single-user operating system Solo written in the programming language Concurrent Pascal. It supports the development of Sequential and Concurrent Pascal programs for the PDP 11/45 computer. Input/output are handled by concurrent processes. Pascal programs can call one another recursively and pass arbitrary parameters among themselves. This makes it possible to use Pascal as a job control language. Solo is the first major example of a hierarchical concurrent program implemented in terms of abstract data types (classes, monitors and processes) with compile-time control of most access rights. It is described here from the user’s point of view as an introduction to another paper describing its internal structure.

This paper describes the implementation of the Solo operating system written in Concurrent Pascal.* It explains the overall structure and details of the system in which concurrent processes communicate by means of a hierarchy of monitors and classes. The concurrent program is a sequence of nearly independent components of less than one page of text each. The system has been operating since May 1975.

The concept of “protection” in programming languages refers to the ability to express directly in the language the desired access control relationships for all objects defined in the language. The use of such mechanisms as data types, scope, parameter passing mechanisms, routines as parameters, abstract data types, and capabilities in Pascal, Concurrent Pascal, Euclid, Clu, and Gypsy are explored via a simple example which embodies many protection problems. The usefulness of language defined and enforced protection mechanisms to the process of formal verification is discussed.

article Exokernel: an operating system architecture for application-level resource management Share on Authors: D. R. Engler M.I.T. Laboratory for Computer Science, Cambridge, MA M.I.T. Laboratory for Computer Science, Cambridge, MAView Profile , M. F. Kaashoek M.I.T. Laboratory for Computer Science, Cambridge, MA M.I.T. Laboratory for Computer Science, Cambridge, MAView Profile , J. O'Toole M.I.T. Laboratory for Computer Science, Cambridge, MA M.I.T. Laboratory for Computer Science, Cambridge, MAView Profile Authors Info & Claims ACM SIGOPS Operating Systems ReviewVolume 29Issue 5Dec. 3, 1995 pp 251–266https://doi.org/10.1145/224057.224076Online:03 December 1995Publication History 700citation13,300DownloadsMetricsTotal Citations700Total Downloads13,300Last 12 Months628Last 6 weeks58 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

Today’s high-performance RISC microprocessors have been highly tuned for integer and floating point application performance. These architectures have paid less attention to operating system requirements. At the same time, new operating system designs often have overlooked modern architectural trends which may unavoidably change the relative cost of certain primitive operations. The result is that operating system performance is well below application code performance on contemporary RISCS. This paper examines recent directions in computer architecture and operating systems, and the implications of changes in each domain for the other. The requirements of three components of operating system design are discussed in detail: interprocess communication, virt ual memory, and thread management. For each component, we relate operating system functional and performance needs to the mechanisms available on commercial RISC architectures such as the MIPS R2000 and R3000, Sun SPARC, IBM RS6000, Motorola 88000, and Intel i860. Our analysis reveals a number of specific reasons why the performance of operating system primitives on RISCS has not scaled with integer performance. In addition, we identify areas in which architectures could better (and cost-effectively) accommodate operating system needs, and areas in which operating system design could accommodate certain necessary characteristics of cost-effective highperformance microprocessors. This work was supported in part by the National Science Foundation under Grants No. CCR-8703049, CCR-8619663, and CCR-8907666, by the Washington Technology Center, by the Digital Equipment Corporation Systems Research Center and External Research Program, and by IBM and AT&T Fellowships. Bershad is now with the School of Computer Science, Carnegie Mellon University. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. 01991 ACM 0-89791 -380 -9/91 /0003 -0108 . ..$1 .50

Protocols for sensor networks are commonly coupled to the specific operating system (OS), for instance TinyOS, involving some drawbacks. First, programmers must learn OS architecture, programming guidelines, sometimes a new programming language, etc. Second, protocols run on the specific OS only, i.e. on the hardware supported by the OS. Third, only selected network simulators, mostly provided by OS, can execute the OS-coupled code.To tackle the problems with interoperability we examined the idea of cross-platform protocol development for sensor networks, i.e. software running on several OSs, and share our experience in this paper.Our primary cross-platform MAC protocol runs on two OSs and on a hardware platform supporting the C programming language. To achieve interoperability we decoupled MAC from OS calls and provided a hardware abstraction layer (HAL) for each OS. We discovered that such an approach does not result in a significant penalty in terms of occupied memory (e.g. smaller by 3 kB than the TinyOS dedicated version) and consumed energy (additional overhead smaller by three orders of magnitude from total tx energy).

Empirical observations of computer operating systems have shown that operating systems are designed with one of two object oriented strategies: a process or a monitor oriented approach. This paper compares the two design approaches in a Concurrent Pascal environment. Resource manager programs that are implemented in conformity with each model are evaluated using software complexity measures and program performance measures. The average complexity of resource manager processes is 94 percent larger than the average complexity of resource manager monitors. The runtime synchronization overhead of the process model program is two-eight times higher than that of its counterpart.

NAND Flash memory solid state disk (hereafter SSD) technology is advancing rapidly in capacity and speed. Also, we envision that byte-addressable NVRAM devices, which is being thought as the future replacement of Flash memory technology will be commercially viable for storage within the next 3–7 years. Modern computer system takes hierarchical organization. It consists of CPU, Main Memory and Storage. This hierarchical organization is natural outcome of economic concern. Modern Operating System is designed to effectively exploit the physical characteristics of the device in each system hierarchy. Process management, memory management, and storage management subsystems are all designed to fill the gaps (speed and space) among the layers in different hierarchies while maximizing cost performance ratio. Current operating system paradigm draws clear line between memory and storage and handles them in very different way. Large scale byte-addressable NVRAM combines the physical characteristics of main memory with the nonvolatility of storage, presenting new challenges for system designers. From the DBMS and Operating System’s point of view, the advancement of this device calls for a reconsideration of legacy operating system architectures that have been designed based upon the notion of system hierarchy: CPU, memory and storage.

The wireless sensor network (WSN) is an interesting area for modern day research groups. Tiny sensor nodes are deployed in a diversity of environments but with limited resources. Scarce resources compel researchers to employ an operating system that requires limited memory and minimum power. Tiny operating system (TinyOS) is a widely used operating system for sensor nodes, which provides concurrency and flexibility while adhering to the constraints of scarce resources. Comparatively, TinyOS is considered to be the most robust, innovative, energy-efficient, and widely used operating system in sensor networks. This paper looks at the state-of-the-art TinyOS and the different dimensions of its design paradigm, programming model, execution model, scheduling algorithms, concurrency, memory management, hardware support platforms, and other features. The addition of different features in TinyOS makes it the operating system of choice for WSNs. Sensing nodes with TinyOS seem to show more flexibility in supporting diverse types of sensing applications.

In Reconfigurable Systems-On-Chip (RSoCs), operating systems can primarily (1) manage the sharing of limited reconfigurable resources, and (2) support communication between reconfigurable accelerators and user applications. It has been shown in previous work that the operating system can dramatically simplify the interface to reconfigurable coprocessors and isolate the programmer from all details of the hardware. A further potential of the operating system is developed here: the operating system can observe accelerators at runtime and dynamically take actions which improve their execution. The strength of involving the operating system consists in achieving better performance without any information from the end user and without changes either in the coprocessor hardware design or in the software application. Specifically, this paper presents an operating system module that monitors reconfigurable coprocessors, predicts their future memory accesses, and performs memory prefetching accordingly; the goal is to hide completely memory-to-memory communication latency. The module uses a lightweight hardware support to detect coprocessors memory access patterns. The effectiveness of the technique is demonstrated for two applications on an embedded RSoC board running the Linux operating system. Significant speedup is achieved compared to the nonprefetching version, and the improvement is obtained in a manner completely transparent to the application programmer.

The programming of the interrupt handling mechanisms, process switching primitives, scheduling mechanisms, and synchronization primitives of an operating system for a multiprocessor require both efficient code in order to support the needs of high-performance or real-time applications and careful organization to facilitate maintenance. Although many advantages have been claimed for object-oriented class hierarchical languages and their corresponding design methodologies, the application of these techniques to the design of the primitives within an operating system has not been widely demonstrated.To investigate the role of class hierarchical design in systems programming, the authors have constructed the Choices multiprocessor operating system architecture using the C++ programming language. During the implementation, it was found that many operating system design concerns can be represented advantageously using a class hierarchical approach, including: the separation of mechanism and policy; the organization of an operating system into layers, each of which represents an abstract machine; and the notions of process and exception management. In this paper, we discuss an implementation of the low-level primitives of this system and outline the strategy by which we developed our solution.

3 - Evolution of Software Technology