π: a new approach to the design of distributed operating systems

Dinesh C. Kulkarni, Arindam Banerji, David L. Cohn
1993 ACM SIGPLAN OOPS Messenger  
A Vision of Computing's Future Modern computer hardware technology allows a single architecture to be used for a range of machines from supercomputers to toasters. Hardware designers have recognized that an architecture should be scalable and system software developers must address the same issue. Scalability means that the architecture must be flexible enough to satisfy diverse hardware and application needs. The key to operating system flexibility is to base the architecture on a high-level
more » ... aph model and to use the generalized object model and metacomputing. The resulting framework is a uniform object model for application and system software. Classically, operating system flexibility means that the architecture must handle various processor capabilities, differing memory and disk sizes and a vast range of peripheral devices. Today, it also includes dealing with multiprocessor systems, diverse network topologies and multimedia input/output. In the future, as radio-based networking becomes common, changes will be dynamic, requiring the flexible operating system to adapt as elements of a distributed system move into and out of range. Different classes of applications have different requirements. The valuable data managed by an OODB must be maintained over long periods of time while a multimedia application requires guaranteed bandwidth. The necessary services and the relative emphasis on different functionalities vary drastically. The π architecture is designed as a framework for flexible operating systems and support software. It is based on this vision of the future and is a first step towards adaptive operating systems. It starts with a high-level model of applications and incorporates facilities for changing abstractions as a fundamental feature. Graph Model for Applications We contend that applications can be effectively modeled as dynamic directed graphs. The nodes of the graph represent objects and the arcs are relationships between the objects. The objects may be active, activatable or simple data objects. The arcs may be object references, activation protocols, delegation targets and so forth. The graph is dynamic since new nodes can be created, old ones can be purged and relationships can be changed. For example, a CAD model of a robot could have a set of data objects containing the descriptions of the robot's components and a set of links that tie these data objects together. The links would represent the "is composed of" relationship. Thus, the robot arm "is composed of" a hinge and a gripper and so on. For another application, an arc connecting two nodes could represent a client-server relationship between two objects. Events make the graph model dynamic. An event could simply be a method invocation by a client object or it could be an asynchronous activation caused by an interrupt or an exception. Mapping onto Resources System software maps abstract application models onto the computational reality as shown in the figure. The programmer first expresses the application through a language and then the run-time environment and operating system control the resources which realize the application. The system software mapping should hide possible changes in the computational reality. Thus, if more processors become available at run time, they should be used them effectively. The services offered by the abstractions and their Abstract Application Model Computational Reality Mapping implementation must be tailorable. For example, a reference which crosses a machine boundary may use a name server but when its target is on the local machine, it should be possible to use a simple pointer. A Framework for Mapping -π π defines a uniform object model for both application and system software. Its architecture is based on three main notions: Resources -elements of the computational reality. Events -the causalities of computation. Interfaces -structured presentation of resources and events. π specifies how these three ideas are combined into a flexible object-based framework. The elements of the computational reality, such as the computational, storage and communication resources, are encapsulated into resource objects. Similarly, abstract resources like locks and messages are also presented as resource objects. A programmer can use these objects in various ways. They can be used as is, or several can be combined or additional services can be defined. Events are typed entities which encapsulate important state changes in the system. They have three aspects: generation, notification and handling. Each object clearly specifies the events that it might generate and the events that it can handle. Notification mechanism allows decoupling of event generation and event handling. Applications see resource objects and events through interfaces. The interfaces contain the type specification for the services provided by the object and also for the events generated by the object.
doi:10.1145/157710.157736 fatcat:ikudidhz4fghrp5pvdoz26yqlu