When distributed systems first appeared, they were programmed in traditional sequential languages, usually with the addition of a few library procedures for sending and receiving messages. As distributed applications became more commonplace and more sophisticated, this ad hoc approach became less satisfactory. Researchers all over the world began designing new programming languages specifically for implementing distributed applications. These languages and their history, their underlying principles, their design, and their use are the subject of this paper. We begin by giving our view of what a distributed system is, illustrating with examples to avoid confusion on this important and controversial point. We then describe the three main characteristics that distinguish distributed programming languages from traditional sequential languages, namely, how they deal with parallelism, communication, and partial failures. Finally, we discuss 15 representative distributed languages to give the flavor of each. These examples include languages based on message passing, rendezvous, remote procedure call, objects, and atomic transactions, as well as functional languages, logic languages, and distributed data structure languages. The paper concludes with a comprehensive bibliography listing over 200 papers on nearly 100 distributed programming languages.

SR is a language for programming distributed systems ranging from operating systems to application programs. On the basis of our experience with the initial version, the language has evolved consider-ably. In this paper we describe the current version of SR and give an overview of its implementation. The main language constructs are still resources and operations. Resources encapsulate processes and variables that they share; operations provide the primary mechanism for process interaction. One way in which SR has changed is that both resources and processes are now created dynamically. Another change is that inheritance is supported. A third change is that the mechanisms for operation invocation-call and send-and operation implementation-proc and in-have been extended and integrated. Consequently, all of local and remote procedure call, rendezvous, dynamic process creation, asynchronous message passing, multicast, and semaphores are supported. We have found this flexibility to be very useful for distributed programming. Moreover, by basing SR on a small number of well-integrated concepts, the language has proved easy to learn and use, and it has a reasonably efficient implementation.

Unlimited copying without fee is permitted provided that the copies are not made nor distributed for direct commercial advantage, and credit to the source is given. Otherwise, no part of this work covered by copyright hereon may be reproduced in any form or by any means graphic, electronic, or mechanical, including photocopying, recording, taping, or storage in an information retrieval system, without the prior written permission of the copyright owner. TRADEMARKS Sun, Sun Microsystems, and the Sun logo are trademarks or registered trademarks of Sun Microsystems, Inc. UNIX is a registered trademark in the United States and other countries, exclusively licensed through X/Open Company, Ltd. All SPARC trademarks, including the SCD Compliant Logo, are trademarks or registered trademarks of SPARC International, Inc. SPARCstation, SPARCserver, SPARCengine, SPARCworks, and SPARCompiler are licensed exclusively to Sun Microsystems, Inc. All other product names mentioned herein are the trademarks of their respective owners.

Abstract not found

Abstract. Java threads are synchronised through primitives based upon monitor concepts developed in the early 1970s. The semantics of Java’s primitives have only been presented in natural language – this paper remedies this with a simple and formal CSP model. In view of the difficulties encountered in reasoning about any non-trivial interactions between Java threads, being able to perform that reasoning in a formal context (where careless errors can be highlighted by mechanical checks) should be a considerable confidence boost. Further, automated model-checking tools can be used to root out dangerous states (such as deadlock and livelock), find overlooked race hazards and prove equivalence between algorithms (e.g. between optimised and unoptimised versions). A case study using the CSP model to prove the correctness of the JCSP and CTJ channel implementations (which are built using standard Java monitor synchronisation) is presented. In addition, the JCSP mechanism for ALTing (i.e. waiting for and, then, choosing between multiple events) is verified. Given the history of erroneous implementations of this key primitive, this is a considerable relief.

Orca is an object-based distributed shared memory system that is designed for writing portable and efficient parallel programs. Orca hides the communication substrate from the programmer by providing an abstract communication model based on shared objects. Mutual exclusion and condition synchronization are cleanly integrated in the model. Orca has been implemented using a layered system, consisting of a compiler, a runtime system, and a virtual machine (Panda). To implement shared objects efficiently on a distributed-memory machine, the Orca compiler generates regular expressions describing how shared objects are accessed. The runtime system uses this information together with runtime statistics to decide which objects to replicate and where to store nonreplicated objects. The Orca system has been implemented on a range of platforms (including Solaris, Amoeba, Parix, and the CM-5). Measurements of several benchmarks and applications across four platforms show that the new Orca system a...

A new coordination model for computations is presented. It offers increased confidence in the correctness of imperative programs and considerable simplification of imperative programming and debugging. In this model, programs consist of formal specifications of computations by recursive function definitions and explicit mappings (coordinations) of these specifications to imperative programs. The consistency between coordination and specification is guaranteed by a special mechanism, called the consistency checker, during the program's execution. It automatically detects any inconsistency by comparisons against symbolic names associated with values. The formal specification of Gaussian elimination and two coordinations that implement a sequential and a parallel algorithm are used to present the model. 1 INTRODUCTION Imperative programming is widely used for expressing scientific computations. It has the advantage of per- Copyright c fl1998 by the Association for Computing Machinery...

Object-based distributed shared memory systems allow processes on different machines to communicate through passive shared objects. This paper describes the implementation of such a system on a transputer grid. The system automatically takes care of placement and replication of objects. The main difficulty in implementing shared objects is updating replicated objects in a consistent way. We use totally-ordered group communication (broadcasting) for this purpose. We give four different algorithms for ordering broadcasts on a grid and study their performance. We also describe a portable runtime system for shared objects. Measurements for three parallel applications running on 128 T800 transputers show that good performance can be obtained. Keywords: Distributed Shared Memory, shared objects, Orca, parallel programming languages, transputers, Parix, totally-ordered group communication, broadcasting. 1 Introduction Distributed shared memory (DSM) is an attractive alternative to message p...

Introduction Imperative programming is commonly used in scientific computing. It offers the advantage of performance but has also considerable drawbacks. The most important one is the explicit store management. It is based on the reuse of stores by destructive assignments. This is essential for performance, but is also one of the most important sources of programming errors. In addition, parallel/distributed imperative programming encompasses the mixture of the description, decomposition, and distribution of computations, and processor communications. This mixture is another source of errors and makes the development of programs highly involved. Functional programming has begun to be seen as an alternative since computations are naturally expressed by recursive function definitions, which are very close to their mathematical description. This idea is used in the programming languages Crystal 1 and EPL 2 and array comprehensions in Haskell<F2

What would it take to make software more dependable? Until now, most approaches have been indirect: some practices – processes, tools or techniques – are used that are believed to yield dependable software, and the argument for dependability rests on the extent to which the developers have adhered to them. This article argues instead that developers should produce direct evidence that the software satisfies its dependability claims. The potential advantages of this approach are greater credibility (since the argument is not contingent on the effectiveness of the practices) and reduced cost (since development resources can be focused where they have the most impact). 1 Why We Need Better Evidence Is a system that never fails dependable? Not necessarily. A dependable system is one you can depend on – that is, in which you can place your reliance or trust. A rational person or organization only does this with evidence that the system’s benefits outweigh its risks. Without such evidence, a system cannot be depended upon, in the same way that a download from an unknown website cannot be said to be ‘safe ’ just because it happens not to harbor a virus.