An efficient implementation scheme of concurrent object-oriented languages on stock multicomputers (extended abstract)

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 environments to support the programming, monitoring and control of applications. The Rosette project at MCC is developing a system architecture for general-purpose concurrent computation based on the Actor model [Agha 1986]. The aim of the Rosette architecture is to support the use of concurrent computers in solving computationally intensive problems whose structure is not statically determined. The architecture will support variable grain size, dynamic resource management, reflection, and heterogeneity. A number of concurrent language proposals have employed computational models that are limited in their applicability because of assumptions such as granularity of concurrency, static process topology, or inherent communications cost. Others, for example, functional programming, cannot be used to model shared, modifiable objects. The Actor model addresses these issues directly. However, the difficulties of using concurrent computers cannot be addressed solely through programming languages. Traditional operating systems treat each process as an independent entity for the purposes of resource management (i.e., for the run-time allocation of processor, storage, and communication resources.) In the context of concurrent applications, effective operation on a concurrent computer requires that communities of processes be managed together, taking into account the ways in which they interact, and providing for the application itself to guide resource management. For example, consider that programming systems often provide only limited support for the control of resource consumption in search problems in the face of combinatorial explosion; further, it is generally recognized that to optimize search performance, it is useful to vary the resources provided depending on how promising intermediate results of a given path are judged to be. The Rosette architecture will allow the programmer to integrate high-level algorithms within the application for dividing resources dynamically among the sub-computations that are spawned. These algorithms will provide an assessment of the progress of the sub-computations, and will be used to make the large number of low-level resource management decisions that are necessary in carrying out the computation. Thus, operating system functionality will be folded into the application. The Rosette architecture has two major components: an interface layer and a system environment . The interface layer provides mechanisms for the monitoring and control of concurrent applications. It supports a uniform view of the system resources and applications through the use of actors and message-passing semantics. The interface layer includes a set of actors that represent the processing, storage and communication resources across the hardware base. The system environment contains actor communities which implement resource management policies , and support for programming concurrent applications. The environment consists of an extensible set of actors that are organized via a class-based object model. These actors provide monitoring, debugging, resource management system simulation, and compilation/transformation facilities. To demonstrate the effectiveness of the Rosette architecture, as well as to drive its development, two classes of applications are being used. The first class is the Rosette system itself: all of the system components necessary for resource management, monitoring, debugging, and program development are being constructed in the Rosette language and will take full advantage of both concurrency and object-oriented programming support. The second category of applications is chosen to be somewhat independent of the Rosette system so as to ensure adequate feed-back concerning applicability to domains other than software engineering. These applications are in the general area of knowledge-based signal interpretation. The Rosette architecture is implemented via a concurrent object-oriented programming language that provides the following features: Inherent concurrency : A declarative approach is needed which allows fine-grained concurrency to arise naturally from the program. If the programmer is forced to express all of the details of the concurrent execution of an application, it becomes difficult to re-map a given program to different concurrent computers which have varying concurrency characteristics. Dynamic creation/modification of objects : This allows the system to be extensible and reconfigurable. Sharing : The language should support mechanisms such as inheritance so that code, structure, and values need not be replicated. Classes : Objects can be organized into classes to permit more effective management of resources, as for example in a very large database. Classes should be first-class objects and hence it should be possible to create classes dynamically. The Rosette language is a high-level language that is translated into a base language that directly expresses concurrent computations in terms of the semantics of the Actor model. The Rosette language extends the base language with data abstraction facilities and a library of classes, and is used to implement the non-built-in actors of the interface layer, components of the system environment, and applications. Using data abstraction extensions to the base language, the Rosette language organizes actors into classes according to common sets of behaviors and local state. Inheritance is used as a means of sharing code and structure that is common among classes. There is considerable evidence, for example [LaLonde 1986] and [Snyder 1987], that a robust class system should support separate hierarchies that represent what is modeled by a class and how some class of objects are actually implemented. Our approach is to use three different kinds of classes to organize the various kinds of actors in a system and information about these actors: abstract classes specify observable requests, responses, and actions; representation classes specify resource management characteristics of implementations; and behavior classes contain the actual implementations. Associated with an abstract class is the set of representations that are available to implement the particular abstraction. Each representation is associated with the behavior class that contains the corresponding implementation. The power of this separation is that each of the three kinds of class may be related to others in a class hierarchy. This means that the relationships between abstract classes are not forced to have the same structure as the relationships among implementations. Sharing via inheritance among behavior classes is related to engineering concerns; relations among abstract classes are dictated by external/observable behavior. As an example, an abstract class might specify the operations available over real-matrices . There are several ways of representing a matrix as a community of actors, and each of these would be specified with appropriate representation and behavior classes. There is a well-defined abstract hierarchy of matrices such as invertible, positive , etc. These abstract kinds of matrices are independent of the various implementations, which may be chosen according to application and hardware resource constraints. The Rosette language embodies a reflective model of the interface layer that is similar to that used in ABCL/R, [Watanabe and Yonezawa 1988]. This model is t

A concurrent object-oriented programming language system for highly parallel data-driven computers and its applications

The design of temporally-predictable real-time software is a major issue in a wide range of computer applications. This paper focuses on the temporal modelling of communication protocols in real-time OSI-based computer networks, and discusses a method which can form the foundation of a tool which gives true temporal representations of such systems. The proposed approach, implemented using the power of a concurrent object-oriented programming language (STRAND), utilises a modelling methodology based on an advanced process/channel model. The paper suggests that the techniques can be applied to a range of problems, illustrated here by an example of an OSI protocol.

Effectively using shared-memory multiprocessors requires substantial programming effort. We present the programming language COOL (Concurrent Object-Oriented Language), which was designed to exploit coarse-grained parallelism at the task level in shared-memory multiprocessors. COOL's primary design goals are efficiency and expressiveness. By efficiency we mean that the language constructs should be efficient to implement and a program should not have to pay for features it does not use. By expressiveness, we imply that the program should flexibly support different concurrency patterns, thereby allowing various decompositions of a problem. COOL emphasizes the integration of concurrency and synchronization with data abstraction to ease the task of creating modular and efficient parallel programs. It is an extension of C++, which was chosen because it supports abstract data type definitions and is widely used. >

ACT++ (Actors in C++) is a concurrent object-oriented language being designed for distributed real-time applications. The language is a hybrid of the actor kernel language and the object-oriented language C++. The concurrency abstraction of ACT++ is derived from the actor model as defined by Agha. This paper discusses our experience in building a concurrent extension of C++ with the concurrency abstraction of the actor model. The current design of ACT++ and its implementation are described. Some problems found in the Agha''s actor model are discussed in the context of distributed real-time applications. The use of ACT++ disclosed the difficulty of combining the actor model of concurrency with class inheritance in an object-oriented language.

Embedded specifications in object-oriented (OO) languages such as Eiffel and Sather are based on a rigorous approach towards validation, compatibility and reusability of sequential programs. The underlying method of design-by-contract is based on Hoare logic for which concurrency extensions exist. However concurrent OO languages are still in their infancy. They have inherently imperative facets, such as object identity, sharing, and synchronisation, which cannot be ignored in the semantics. Any marriage of objects and concurrency requires a trade-off in a space of intertwined qualities. The paper summarises our work on a type system, calculus and an operational model for concurrent objects in a minimal extension of the Eiffel and Sather languages (cSather). We omit concurrency control constructs and instead use assertions as synchronisation constraints for asynchronous functions. We show that this provides a framework in which subtyping and concurrency can coexist.

A problem which confronts the developers of concurrent logic programming (CLP) systems concerns the design of the programming environment, particularly the provision of debugging tools. Debugging tools are useful for many activities besides identifying bugs: they can help in program testing and demonstration, in software experiments, and in teaching the language semantics. For CLP languages the questions of what debugging tools should be provided, and of how they should be used, are still open. Although the languages are closely related to other logic programming and concurrent programming languages, they are sufficiently different that new debugging techniques are required. This paper describes a primarily channel-oriented debugging methodology and a set of debugging tools that we have developed in the light of our experience in using and teaching the CLP language Parlog. With these tools a programmer can test a program by observing communication on channels, opening up a process to examine the activity on internal channels and, if necessary, to check in detail the execution steps of a process. Almost all of the ideas, which are equally applicable to other CLP languages, have been implemented in two commercial Parlog systems. As well as fulfilling the needs of existing users of CLP languages, we believe that the tools emphasise the attractions of CLP as a concurrent programming paradigm, since they are made possible by the unique attributes of CLP.

It is difficult to map the execution model of multithreading languages (languages which support fine-grain dynamic thread creation) onto the single stack execution model of C. Consequently, previous work on efficient multithreading uses elaborate frame formats and allocation strategy, with compilers customized for them. This paper presents an alternative cost-effective implementation strategy for multithreading languages which can maximally exploit current sequential C compilers. We identify a set of primitives whereby efficient dynamic thread creation and switch can be achieved and clarify implementation issues and solutions which work under the stack frame layout and calling conventions of current C compilers. The primitives are implemented as a C library and named StackThreads. In StackThreads, a thread creation is done just by a C procedure call, maximizing thread creation performance. When a procedure suspends an execution, the context of the procedure, which is roughly a stack frame of the procedure, is saved into heap and resumed later. With StackThreads, the compiler writer can straightforwardly translate sequential constructs of the source language into corresponding C statements or expressions, while using StackThreads primitives as a blackbox mechanism which switches execution between C procedures.

In object-oriented programming, updates to the state variables of objects (by the methods of the object) have to be protected through semaphores to ensure mutual exclusion. Semaphore operations are invoked each time an object is accessed, and this represents significant run-time overhead. This is of special concern in cost-conscious, small-size embedded systems-such as those used in automotive applications-where costs must be kept to an absolute minimum. Object-oriented programming can be feasible in such applications only if the OS provides efficient, low-overhead semaphores. The authors present a new semaphore implementation scheme which saves one context switch per semaphore lock operation in most circumstances and gives performance improvements of 18-25% over traditional semaphore implementation schemes.

Saraswat recently introduced the framework of concurrent constraint programming [14]. The essence of the framework is that computations consist of concurrent agents interacting by communicating constraints. Several concurrent constraint programming languages have been defined. They differ in the kinds of constraints that can be used as well as the kinds of operations on constraints which are available. In this paper we introduce a very simple concurrent constraint language we call Lucy, designed to closely mimic the actor model of computation. Agents can communicate only by the posting of constraints upon bags (un-ordered collections possibly with duplicate elements). This very impoverished concurrent constraint language is a syntactic subset of Janus, a concurrent constraint language which closely resembles concurrent logic programming languages such as Guarded Horn Clauses [21], Strand [5], Parlog [2] and Flat Concurrent Prolog [13]. By identifying the subset of Janus which is an actor language, we elucidate the relationship between actors and concurrent logic programming (and its generalization as concurrent constraint programming). Lucy is best not thought of as a unification of logic and constraint programming with actor and object-oriented programming, but as the missing link between these programming language genera.

Presents a framework to define a semantics for a real-time object-oriented programming language and to verify programs written in the language. The semantics is defined as the collection of translation rules that map the syntactic constructions of the language into expressions in a process calculus extended with the notion of time. By using the expressive capabilities of the calculus, the semantics can appropriately capture temporal features of the language such as timeout exception and execution time, and concurrent object-oriented features such as concurrency, class, and object creation. Particularly, since it can restrict the number of concurrent activities which take place simultaneously, it allows one to analyze and predict the temporal and behavioral properties even of programs executed with a number of processors smaller than the number of active objects. Through an example, we illustrate a method of analyzing real-time programs. >

We are engaged in the design of Grace, a new object-oriented open source programming language aimed at instructors and students in introductory programming courses. Grace aims to include features that have been found useful in software practice, while allowing multiple different teaching approaches without requiring that concepts be introduced to students before they are ready. While many aspects of Grace's design will be familiar to most object-oriented programmers, Grace cleanly separates the concepts of object, class, and type, and so Grace offers more options for creating objects than most other languages. We have written these patterns to explain how Grace programmers should go about creating objects.

The progress of computer and numerical technique in recent years allows people not only complex numerical simulation but also resolution of inverse problems. In the inverse analysis, it is important to pursue higher quality of gradient computation. It is called as the sensitivity analysis in general. This is the most bone-crushing thema in the analysis. In this study, the authors propose the automatic differentiation as a new approach applied to the optimal control problems. The optimal control and identification problems in incompressible viscous flows are performed in this research. The Navier-Stokes equations with incompressibility constraint is employed as state equation for the viscous flow. The forward mode automatic differentiation computes the partial derivatives according to the differentiation rule of a composite function whenever basic operation is performed. This method is efficiently implemented by operator over-loading technique, which is depending on object oriented programming languages such as C++.

Programs written in concurrent object-oriented languages, especially ones that employ thread-safe reusable class libraries, can execute synchronization operations (lock, notify, etc.) at an amazing rate. Unless implemented with utmost care, synchronization can become a performance bottleneck. Furthermore, in languages where every object may have its own monitor, per-object space overhead must be minimized. To address these concerns, we have developed a meta-lock to mediate access to synchronization data. The meta-lock is fast (lock + unlock executes in 11 SPARC™ architecture instructions), compact (uses only two bits of space), robust under contention (no busy-waiting), and flexible (supports a variety of higher-level synchronization operations). We have validated the meta-lock with an implementation of the synchronization operations in a high-performance product-quality Java™ virtual machine and report performance data for several large programs.

Eunice/ITRON is a control system development environment, whose target machines are ITRON machines. The core of Eunice/ITRON is a full-lifecycle-support language Nike. In Eunice/ITRON, except final performance tuning, development from abstract description level through semi-implementation level can be done on utilities-rich UNIX workstations. This way rapid and efficient development of control systems is attained. Nike is a concurrent object-oriented language. Dynamic behavior of each object can be described in state-transition model. In addition, to let the development process go forward and backward seamlessly, Nike provides refinement mechanism regarding states and their transitions, which can be validated at run-time. It not only conduces early executability, but also is the major driving force of refinement. Our implementation of the Nike compiler on an ITRON2-compliant operating system is discussed; and also that of Nikechat, a graphical executor under the X Window, of the system specified in Nike. >