The heart of object-oriented concurrent programming

simpA: An agent-oriented approach for programming concurrent applications on top of Java

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

This collection of original research provides a comprehensive survey of developments at the leading edge of concurrent object-oriented programming. It documents progress—from general concepts to specific descriptions—in programming language design, semantic tools, systems, architectures, and applications. Chapters are written at a tutorial level and are accessible to a wide audience, including researchers, programmers, and technical managers. The problem of designing systems for concurrent programming has become an increasingly important area of research in computer science with a concomitant increase in the popularity of object-based programming. Because parallelism is a natural consequence of the use of objects, the development of systems for concurrent object-oriented programming is providing important software support for a new generation of concurrent computers.

A program is composed of commands that run within a computer or an electronic circuit. Programming is a mathematical methodology to write a program and to encode the algorithm into a notation. It can be classified into two groups such as system and application programming. System programming is a branch of the general programming that is composed of low-level instructions which are used to operate and handle computer hardware. Application programming is considered as the improved version of the computer programs that can perform specific tasks. One of the application programming types is the object-oriented programming (OOP) which is about how information is represented in human mind. OOP is useful to provide easy modeling in design and developing real entities. This approach is aimed to model the entities and the relationships existing between them. OOP enables to define the required classes to create the objects and to apply modifications on them. The inherent properties of OOP are modularity, extensibility, and reusability. This chapter provides a substantial survey of OOP.

Fine-grained concurrent object-oriented programming (COOP) models can simplify the programming of irregular parallel applications but are often perceived as inefficient. In this paper, we study implementation techniques to obtain efficient parallel execution of fine-grained COOP languages using a medium-sized protein dynamics program. We found that even with high data locality and good sequential code efficiency, an implementation using only thread-oriented optimizations and software multithreading fails to achieve parallel efficiency. The two major sources of overhead are the lack of processor-level data reuse and fine-grained threads for remote object accesses. Two processor-oriented optimizations, processor-level caching and communication grouping, overcome these inefficiencies and achieve performance comparable to a highly-tuned SPMD program.

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.

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

The recent turn towards multicore processing architectures has made concurrency an important part of mainstream software development. As a result, an increasing number of developers have to learn to write concurrent programs, a task that is known to be hard even for the expert. Language designers are therefore working on languages that promise to make concurrent programming "easier". However, the claim that a new language is more usable than another cannot be supported by purely theoretical considerations, but calls for empirical studies. In this paper, we present the design of a study to compare concurrent programming languages with respect to comprehending and debugging existing programs and writing correct new programs. A critical challenge for such a study is avoiding the bias that might be introduced during the training phase and when interpreting participants' solutions. We address these issues by the use of self-study material and an evaluation scheme that exposes any subjective decisions of the corrector, or eliminates them altogether. We apply our design to a comparison of two object-oriented languages for concurrency, multithreaded Java and SCOOP (Simple Concurrent Object-Oriented Programming), in an academic setting. We obtain results in favor of SCOOP even though the study participants had previous training in writing multithreaded Java programs.

There are various logic-based approaches to modelling concurrent programming. The use of logic for system development concerns both the specification step and the study of the operational aspects (through proof analysis and construction) of such development. This means that we have to consider different logical systems for different uses of logic. Moreover, we can also consider concurrency from both points of view: we want to reason and to specify systems where some concurrency aspects are involved, but also to have some operational interpretation of concurrency within logic (focusing on the concept of proof). For this purpose, it seems clear that we have to identify and to study, on the one hand, the role and the treatment of objects (representation, inheritance, modularity, communication, and so on) in this context, and, on the other hand, the interaction of work on proofs and concurrency with the Object-Oriented Programming paradigm.The ECOOP’96 workshop on ‘Proof Theory of Concurrent Object-Oriented Programming’ took place in Linz, Austria, in July 1996. Its objective was to provide an integrated forum for the presentation of research and the exchange of ideas and experiences in the topics concerned with proofs, concurrency and object-oriented programming (specification, proof development, and so on). The call for papers for this Special Issue of Mathematical Structures in Computer Science can be considered to have been a natural scientific continuation of the workshop.The papers selected for this Special Issue address some of the topics discussed in the workshop. They present different alternative frameworks that are effectively based on a proof-theoretic approach. They illustrate, from different points of view, the interest, potentialities and difficulties of dealing with such an approach in the design of object-based concurrent systems.

A status report is presented on a project aimed at implementing new technologies, such as concurrent processing, object-oriented programming, and artificial intelligence techniques, in distribution system control centers. The applications functions include monitoring, diagnosing, switching, and service restoration. A major concern in implementing such technologies is how best to interface existing software (number crunching) with the new tools. The project investigates the possibility of solving the integration problem by using conventional language extensions for coding the new applications. All the required extensions are based on a distributed real-time system which supports process-spawning and message-passing. This project forms part of a more general effort which includes applications to a broader class of power system problems and to such areas as the real-time control of telephony switching systems. >

Concurrent object-oriented programming systems require support for concurrency control, to enforce consistent commitment of changes and to support program-initiated rollback after application-specific failures. We have explored three different concurrency control models atomic blocks, serializable transactions, and commit-serializable transactions - as part of the MELD programming language. We present our designs, discuss certain programming problems and implementation issues, and compare our work on MELD to other concurrent object-based systems.

Learning how to design and implement a program is hard. Teaching methods and textbooks on Java programming often treat a new subject in terms of syntax and examples. Little attention is paid to systematically designing programs with these new concepts. Research has shown that such a complex task requires not only conceptual knowledge, but also explicit procedural support.In this paper, we investigate the effect of combining conceptual and procedural guidance to teaching and learning concurrent programming. We build on earlier research in which we have introduced such a structured design methodology which divides the development of multi-threaded Java programs into a sequence of explicit, manageable steps: the Steps Plan.We present our experiences with applying the Steps Plan in an introductory course on object-oriented programming, with multithreading. The main questions addressed are: What problems did the students encounter in direct relation to the Steps Plan?, and What general problems surfaced?As to the first question, two important issues were that using a relatively far developed sequential solution as a stepping stone towards a multi-threaded solution wrong-footed some students, and that remedying race condition situations turned out to be supported at a too high level of abstraction.As to the second question, two notable issues were that deciding on the right amount and type of concurrency by themselves is maybe too difficult for students at this level, and that the notion of (establishing) correctness or quality of a solution is, different from the sequential case, not intuitively clear to students.For these issues, the paper recommends remedies and indicates directions for future work. We discuss the consequences for education as regards teaching materials and forms of teaching.

This paper discusses knowledge sharing (inheritance) mechanisms for Object-Oriented Programming (OOP) in the context of concurrent (distributed) languages. We review three different schemes: inheritance, delegation and copy. A fourth model, called recipe-query, is presented and all are compared and criticized. Techniques relying on the shared memory assumption are rejected. We point out the conflict between distributing knowledge among objects and the synchronization of concurrent objects.

Object databases are usually referring to those data management products that are specifically designed for use with an object programming language and are very closely coupled with one or more object programming languages. Typically, the most of the recent OODBMSs use C++ and/or Smalltalk languages as their database programming language. The application programmer may access database objects directly using the database operations in the programming language, or may perform associative lookups of objects using the query language. Unfortunately, the latter includes many problems concerning both the design of such languages and their implementation. Two significant development lines are recently at disposal: ODMG-93 standard with its language OQL [Ca93] and the work proposed by the ANSI X3H2 group well-known as SQL3 [Me94] that stores objects in special kinds of columns in relations.

Object-based sequential programming has had a major impact on software engineering. However, object-based concurrent programming remains elusive as an effective programming tool. The class of applications that will be implemented on future high-bandwidth networks of processors will be significantly more ambitious than the current applications (which are mostly involved with transmissions of digital data and images), and object-based concurrent programming has the potential to simplify designs of such applications. Many of the programming concepts developed for databases, object-oriented programming and designs of reactive systems can be unified into a compact model of concurrent programs that can serve as the foundation for designing these future applications.There are several key questions in developing a model of concurrent-objects for wide-area computing. Foremost among the concerns is the difficulty associated with managing concurrent interactions, particularly when a multitude of machines interact. This is the main topic of this research. Additionally, issues of security and fault-tolerance are central to wide-area computing. How can a secure computation be carried out if the data and procedure reside at different machines? If a computation involves several thousand machines — as would be expected for a computation on the world-wide web — is it realistic to allow an unknown party to have exclusive access to a resource? That party may crash requiring a major roll-back effort. Is it reasonable to queue a caller for access to a resource when the resource manager could possibly fail, causing the caller to block? In this case, it may be more efficient to reject the call if the resource is not readily available. We seek a model that allows us to experiment with a variety of questions of this nature.