Practical framework for contract-based concurrent object-oriented programming (original) (raw)
Related papers
Systematic concurrent object-oriented programming
Communications of the ACM, 1993
udging by the looks of the two parties, the marriage between concurrent computation and object-oriented programming-a union much desired by practitioners in such fields as telecommunications, highperformance computing, banking and operating systems-appears easy enough to arrange. This appearance, however, is deceptive: the problem is a hard one. This article points the way toward a pos,;ible solution. The precise problem examined here is restricted to: What is the simplest, smallest and most convincing extension to the method of systematic object-oriented software construction that can address the needs oJ concurrent and distributed computing as well as those of sequential computation? The article does not claim to discuss concurrency and distribution in a general and unbiased way. Rather, it takes the object-oriented paradigm as a given (on the basis of its contributions to the production of quality software) and investigates how best to adapt it so it covers both concurrent and sequentia;[ applications. The word "systematic" as used in the title of the article will provide strong gqaidance to our search for this minimal extension. We are interested in an approach that makes it possible to reason about software systems in a precise way, by extending to the concurrent case the systematic techniques, known as 'design by contract', which can be applied to the systematic (~dthough not necessarily fully formal) development of sequential object-oriented software. A word ofwaming as to the actual ambition of the model discussed here. No claim is made that the work as reported is final, and a number of possible criticisms are discussed in the final section. I do think, however, that in its discussion of how the mutual attraction between object orientation and concurrency can be turned into a reasonably happy marriage, this article raises a number of questions. Although crucial for both COMMUNICATIONS
Concurrent Object-Oriented Programs: From Specification to Code
Formal Methods for Components and Objects, First International Symposium, FMCO 02, 2003
In this paper we put forward a concurrent object-oriented programming language in which concurrency is tightly integrated with objects. Concurrency is expressed by extending classes with actions and allowing methods to be guarded. Concurrency in an object may be hidden to the outside, thus allowing concurrency to be introduced in subclasses of a class hierarchy. A disciplined form of intra-object concurrency is supported. The language is formally defined by translation to action systems. Inheritance and subtyping are also considered. A theory of class refinement is presented, allowing concurrent programs to be developed from sequential specifications. Our goal is to have direct rules for verification and refinement on one hand and a practical implementation on the other hand. We briefly sketch our implementation. While the implementation relies on threads, the management of threads is hidden to the programmer.
SCOOP – A Contract-Based Concurrent Object-Oriented Programming Model
Lecture Notes in Computer Science, 2010
SCOOP is a concurrent object-oriented programming model based on contracts. The model introduces processors as a new concept and it generalizes existing object-oriented concepts for the concurrent context. Simplicity is the main objective of SCOOP. The model guarantees the absence of data races in any execution of a SCOOP program. This article is a technical description of SCOOP as defined by Nienaltowski [11] and Meyer [7, 9, 10].
Submitted to TOOLS USA 2003 Concurrent Object-Oriented Programming: The MP-Eiffel Approach
2008
This article evaluates several possible approaches for integrating concurrency into object-oriented programming languages, presenting afterwards, a new language named MP-Eiffel. MP-Eiffel was designed attempting to include all the essential properties of both concurrent and object-oriented programming with simplicity and safety. A special care was taken to achieve the orthogonality of all the language mechanisms, allowing their joint use without unsafe side-effects (such as inheritance anomalies). 1
Abstract Writing Concurrent Object-Oriented Programs
1989
This paper considers a number of ways in which concurrent programs may be expressed within an object-oriented framework. It goes on to describe work investigating the expression of highly parallel programs in a conventional object-oriented language (Smalltalk-80). The relevance of this work to a new parallel object-oriented system is discussed. An implementation of an ‘eager ’ evaluator is described, together with a ‘throttling ’ mechanism capable of limiting the generation of concurrent processes. A system for suspending all processes performing a parallel computation is discussed. Finally, further work in investigating debugging environments for concurrent objectoriented systems is outlined. Concurrent Object-Oriented Systems There has been an increasing interest in recent years in what is called object-oriented programming, accompanied by a diversification of opinion. There seems to be little agreement about what is meant by the term ‘object’, or whether a particular programming ...
Formal Aspects of Computing, 2008
The SCOOP model extends the Eiffel programming language to provide support for concurrent programming. The model is based on the principles of Design by Contract. The semantics of contracts used in the original proposal (SCOOP_97) is not suitable for concurrent programming because it restricts parallelism and complicates reasoning about program correctness. This article outlines a new contract semantics which applies equally well in concurrent and sequential contexts and permits a flexible use of contracts for specifying the mutual rights and obligations of clients and suppliers while preserving the potential for parallelism. We argue that it is indeed a generalisation of the traditional correctness semantics. We also propose a proof technique for concurrent programs which supports proofs—similar to those for traditional non-concurrent programs—of partial correctness and loop termination in the presence of asynchrony.
Concurrent Object-Oriented Programming: The MP-Eiffel Approach
The Journal of Object Technology, 2004
This article evaluates several possible approaches for integrating concurrency into object-oriented programming languages, presenting afterwards, a new language named MP-Eiffel. MP-Eiffel was designed attempting to include all the essential properties of both concurrent and object-oriented programming with simplicity and safety. A special care was taken to achieve the orthogonality of all the language mechanisms, allowing their joint use without unsafe side-effects (such as inheritance anomalies). CONCURRENT OBJECT-ORIENTED PROGRAMMING: THE MP-EIFFEL APPROACH MP-Eiffel aims to be a safe concurrent language, where unsynchronized accesses to shared resources are statically prevented (unlike, for example, Java). Concurrent activities are performed by abstract processors (a term reused from Meyer's approach to concurrency: SCOOP), which may access shared objects, and also communicate directly with each other through a mechanism named "trigger". Concurrent access to objects use a readers-writer semantics, in which side-effect free accesses may occur simultaneously (the only acceptable form of intra-object concurrency), but at most only one writer is allowed to proceed. The type system is used to safely control the access to shared objects, with the introduction of two type modifiers: shared and remote. SCOOP semantics of reusing the separate part of preconditions for conditional synchronization is also used in MP-Eiffel. The exception handling mechanism is adapted for a concurrent environment in which a synchronous communication mechanism (either when accessing a shared object, or when sending a synchronous message to another processor) retains Eiffel's normal semantics. For asynchronous communication between processors the message communication status is verifiable by special direct inter-processor communication functions (synchronous). MP-Eiffel takes the view of removing from programs all time dependent requirements (scheduling, exclusion, etc.) which do not affect their logical semantics, delegating them either to the language semantics (exclusion, deadlocks) or to a separate description program (scheduling, real-time requirements). This way the programs are safer and easier to understand.
The ClassiC programming language and design of synchronous concurrent object oriented languages
Journal of Systems Architecture, 1998
Many real-time systems make use of concurrent programming systems and are often designed using object oriented design methods. Concurrent Object Oriented Languages (COOLS) are a class of programming language that integrates the facilities of concurrent and object oriented programming in an integrated rather than orthogonal manner. With the increasing interest in the use of object oriented languages such as C++ for the programming of embedded and real-time systems COOLs seem to be a natural candidate for such tasks. Several COOLs have been described in the literature which address the requirements of concurrent programming, inter-process communication (IPC) and synchronisation in various dierent ways. This paper discusses one such language, ClassiC, and examines the approach to this problem taken in its design. In particular, it is shown that the features of ClassiC allow derivation of active classes from other active classes. It is shown how this property can be used to overcome some of the problems associated with synchronous IPC schemes while maintaining the advantages of them and how the use of the asynchronous IPC model allows ver-i®cation of synchronisation and deadlock properties based on the use of CSP methods.
2008 13th Asia-Pacific Computer Systems Architecture Conference, 2008
This is a discussion paper on a very important topic that is about to become mainstream. It deals with the issues of software engineering in concurrent systems. It introduces this topic and illustrates the arguments for a change of perspective. It underlines these arguments with two examples, an asynchronous stream-based programming model and an asynchronous thread-based virtual machine model. Both support concurrency on very different abstractions but both capture similar support for concurrency engineering.