Traditional Operating Systems Research Articles

Buffer Management Issues in the Implementation of Fast Interprocess Communication

This paper presents our experience with building a cross-domain object invocation mechanism that is conscious about memory usage. Cross-domain object invocation issues are very similar to cross-domain procedure call issues. Although the cross-domain procedure call performance issues have been discussed widely, there is very little reference to issues regarding space. It is a typical example of a case where the issues arising in practice are more complicated than the ones described in the reference literature. Our mechanism is discussed in terms of the Spring modular operating system, but the same principles are applicable to other operating systems. The Spring system is a distributed computing environment running on a networked collection of computers. Each individual Spring system is based around a microkernel known as the nucleus. The nucleus is structured to support fast and secure cross address-space object invocations. Most of the traditional operating system services are provided by servers running as user-mode domains. In a system such as Spring, fast, secure, and space-efficient cross-domain invocation is extremely important. Argument buffers are used to pass data from one process to another. For fast cross address-space procedure calls the maximum size of this buffer should accommodate a small number of page frames. In typical contemporary architectures this size varies between 5 and 10K. In a system such as Spring, where there is a large number of active calls, this size leads to excessive memory usage. Earlier measurements have shown that at run-time the marshalled form of the arguments of most of the calls is less than a hundred bytes. Copying page size objects is the only notable exception. Our implementation uses small 128 byte buffers by default. A very fast mechanism is used to extend the small buffer for calls with marshaled arguments that do not fit in the small buffer. Therefore, it is very space efficient and does not affect the overall system performance. Measurements from our implementation that support these claims are presented.

Developing a natural language interface for the UNIX operating system

Traditional operating system command languages have been shown to cause significant loss of productivity to novice and intermediate computer users when compared with alternative modes of interaction such as direct manipulation, menu selection, and natural language communication. Within the last decade, significant advances in the areas of direct manipulation and menu selection have resulted in the development of user interface management systems. These systems consist of tools for the specification, design, evaluation, and run-time support of graphical user interfaces. Our work extends the domain of user interface management systems to include development of restricted natural language interfaces to operating systems.This report discusses the use of the NALIGE user interface management system int he development of a natural language interface for the Unix operating system. Specifically, the task of developing such an interface is reduced to producing a set of well-formed specifications which describe lexical, syntactic, semantic, and pragmatic aspects of the selected application domain. These specifications are used by NALIGE to construct an autonomous natural language interface which exhibits the desired linguistic and functional behavior.

Multiuser processes and shared capability lists for shared workspace collaboration

With the recent interest in collaboration software and tools, there is a growing need and demand for operating systems to support and facilitate the construction of this new application. This article investigates desirable features for shared workspaces and discusses the relevance of operating systems supporting them. Two operating system mechanisms are proposed to support multiuser tool development and sharing of user privileges in a collaborative session. The first mechanism, multiuser processes, is a generalization of traditional operating system processes. The second mechanism, shared capabilities lists, is used to achieve finer control of object sharing among participants. An initial prototype implementation based on BSD 4.3 UNIX is described. Implementation alternatives and associated issues are discussed.

A systems approach to chemical management by manufacturing firms in an environmentally constrained world

The regional and global environmental perturbations resulting from the effects of human economic activity on fundamental biological, chemical, and physical systems can no longer be ignored. Indeed, a complex and expanding set of statutory and regulatory responses, directed in large part at industrial and manufacturing activity, demonstrates society's increasing understanding of this process. These developments have driven the evolution of industry environmental compliance and management systems. In particular, integrated chemical management systems (“ICMS”), which consist of two subsystems — a “data subsystem” and a “management subsystem,” have become both more complex and more integrated into traditional business operating and management systems. Three stages in ICMS evolution are defined and described: stage I, the presystemic stage; stage II, the static system stage; and stage III, the interactive system stage.

ES‐Kit: An object‐oriented distributed system

AbstractThis paper describes the design, implementation, and performance of ES‐Kit, a distributed object‐oriented system being developed by the Experimental Systems Project at the Microelectronics and Computer Technology Corporation. The operating system consists of a kernel and a set of Public Service Objects which dynamically extend the functionality of the kernel by providing several traditional operating system services when required by application objects. Applications for the ES‐Kit environment are written in GNU C++ and do not require additional language primitives for distributed execution. Initial performance results from a representative set of applications indicate that the object‐oriented paradigm provides a powerful solution to distributed programming.

Architectural issues in microkernel-based operating systems: the Chorus experience

An important trend in operating system development is the restructuring of the traditional monolithic operating system kernel into independent servers running on top of a minimal nucleus or ‘microkernel’. This approach arises out of the need for modularity and flexibility in managing the ever-growing complexity caused by the introduction of new functions and new architectures. In particular, it provides a solid architectural basis for distribution, faulttolerance and security. Microkernel-based operating systems have been a focus of research for a number of years, and are now beginning to play a role in commercial UNIX ∗ ∗ UNIX is a trademark of UNIX Systems Labs, Inc systems. The ultimate feasibility of this attractive approach is not yet widely recognized, however. A primary concern is efficiency: can a microkernel-based modular operating system provide performance comparable to that of a monolithic kernel when running on comparable architectures? The elegance and flexibility of the client-server model may exact a cost in message-handling and context-switching overhead. If this penalty is too great, commercial acceptance will be limited. Another pragmatic concern is compatibility: in an industry relying increasingly on portability and standardization, compatible interfaces are needed not only at the level of application programs, but also for device drivers, streams modules and other components. In many cases, binary as well as source compatibility is required. These concerns affect the structure and organization of the operating system. The Chorus team has spent the past six years studying and experimenting with UNIX ‘kernelization’ as an aspect of its work in distributed and real-time modular systems. Aspects of the current Chorus † † Chorus is a registered trademark of Chorus systèmes. system are examined here in terms of its evolution from the previous version. The focus is on pragmatic issues such as performance and compatibility, as well as considerations of modularity and software engineering.

Threads and input/output in the synthesis kernal

The Synthesis operating system kernel combines several techniques to provide high performance, including kernel code synthesis, fine-grain scheduling, and optimistic synchronization. Kernel code synthesis reduces the execution path for frequently used kernel calls. Optimistic synchronization increases concurrency within the kernel. Their combination results in significant performance improvement over traditional operating system implementations. Using hardware and software emulating a SUN 3/160 running SUNOS, Synthesis achieves several times to several dozen times speedup for UNIX kernel calls and context switch times of 21 microseconds or faster.

Rosette: An object-oriented concurrent systems architecture

A number of concurrent computers have been designed, such as [Ametek 1988] and [NCUBE 1986]. Taking advantage of concurrency on these computers will require new languages, operating systems, and en...

Recovery management in QuickSilver

One price of extensibility and distribution, as implemented in QuickSilver, is a more complicated set of failure modes, and the consequent necessity of dealing with them. In traditional operating systems, services ( e.g. , file, display) are intrinsic pieces of the kernel. Process state is maintained in kernel tables, and the kernel contains explicit cleanup code ( e.g. , to close files, reclaim memory, and get rid of process images after hardware or software failures). QuickSilver, however, is structured according to the client-server model, and as in many systems of its type, system services are implemented by user-level processes that maintain a substantial amount of client process state. Examples of this state are the open files, screen windows, address space, etc., belonging to a process. Failure resilience in such an environment requires that clients and servers be aware of problems involving each other. Examples of the way one would like the system to behave include having files closed and windows removed from the screen when a client terminates, and having clients see bad return codes (rather than hanging) when a file server crashes. This motivates a number of design goals: Properly written programs (especially servers) should be resilient to external process and machine failures, and should be able to recover all resources associated with failed entities. Server processes should contain their own recovery code. The kernel should not make any distinction between system service processes and normal application processes. To avoid the proliferation of ad-hoc recovery mechanisms, there should be a uniform system-wide architecture for recovery management. A client may invoke several independent servers to perform a set of logically related activitites (a unit of work ) that must execute atomically in the presence of failures, that is, either all the related activities should occur or none of them should. The recovery mechanism should support this. In QuickSilver, recovery is based on the database notion of atomic transactions , which are made available as a system service to be used by other, higher-level servers. This allows meeting all the above design goals. Software portability is important in the QuickSilver environment, dictating that transaction-based recovery be accessible to conventional programming languages rather than a special-purpose one such as Argus [Liskov84]. To accommodate servers with diverse recovery demands, the low-level primitives of commit coordination and log recovery are exposed directly rather than building recovery on top of a stable-storage mechanism such as in CPR [Attanasio87] or recoverable objects such as those in Camelot [Spector87] or Clouds [Allchin&McKendry83].

The Application of Multiprocessors to Scientific Problems: The Potential and the Pitfalls

The objective of research on the MIDAS project is to demonstrate the viability of a multiprocessor approach to computing and to develop a general purpose, extensible architecture which can be used to address the growing computational requirements of the scientific community. To be successful in this endeavor, however, requires more than simply designing, or even constructing, new hardware structures. To achieve high performance on future systems will require software approaches which can exploit parallel architectures as fully as possible. A critical issue, therefore, is to understand the functional requirements of a large class of applications. The requirernents must be critically examined and, in many cases, new approaches to old algorithms investigated. For highly parallel systems to be effectively utilized, they must be flexible and adaptable to specific application requirements. In particular, they will probably need a variety of control and communication mechanisms to facilitate load balancing of a problem and to minimize bottlenecks in performance. The effective utilization of highly parallel architectures, however, raises many new questions. Traditional operating system structures must, for example, be re-examined. Fault-tolerant environments, with error recovery capability, become increasingly important as the number of components and processors increases. Language extensions to support parallel operations are obviously required, and ultimately new languages are needed to explicitly exploit parallel constructs. A new generation of development and debugging tools will be necessary in order to examine programn performance and operation in an asynchronous parallel environment.

A multilayered operating system for microcomputers

Traditionally, programs on microcomputers have been accessing the hardware through a simple monitor. Recent years, however, have seen the evolution of general operating systems for microcomputers. With these, microcomputer systems follow the history of the mainframes. General operating systems have several advantages. They enhance the possibilities of the hardware and define standard interfaces for application programs. However, the price one has to pay for these benefits is high. The operating system itself will take a large part of the available resources and, for many systems, it will hinder a user-oriented interface of the application programs. These disadvantages, which are serious enough for mainframes, can make the traditional general operating system unacceptable for microcomputer systems. As an alternative, we will propose a multi-level operating system, based on ideas from the ISO Open System Interconnection Basic Reference Model [1]. This system combines the advantages of having only a thin layer of software between application programs and the hardware, with the functionality offered by general operating systems.