To save content items to your account,
please confirm that you agree to abide by our usage policies.
If this is the first time you use this feature, you will be asked to authorise Cambridge Core to connect with your account.
Find out more about saving content to .
To save content items to your Kindle, first ensure no-reply@cambridge.org
is added to your Approved Personal Document E-mail List under your Personal Document Settings
on the Manage Your Content and Devices page of your Amazon account. Then enter the ‘name’ part
of your Kindle email address below.
Find out more about saving to your Kindle.
Note you can select to save to either the @free.kindle.com or @kindle.com variations.
‘@free.kindle.com’ emails are free but can only be saved to your device when it is connected to wi-fi.
‘@kindle.com’ emails can be delivered even when you are not connected to wi-fi, but note that service fees apply.
The task of programming distributed applications in Ada may be addressed in several ways. Most of these require the application developer to factor the hardware configuration into software design very early in the development process. The resulting software is sensitive to changes in hardware, does not lend itself to design iteration, is not easily transportable across different hardware configurations, and is not stable against changes during the lifecycle of the application.
In Section 3, we describe an approach that aims at separation of concerns between program design and program partitioning for distributed execution. The entire application is written as a single Ada program using the full capabilities of the language for program structuring, separate compilation, and type checking. Then in a distinct second phase of design, the program is partitioned and prepared for distributed execution. Advantages of a two-phase design approach are discussed. Section 4 reviews related work and presents a comparative evaluation. Section 5 describes the notation used to express program partitioning. Section 6 revisits the issue of what Ada entities should be distributable.
Two implementations of this approach have been completed and tested with the Ada Compiler Validation Capability (ACVC) test-suite. Implementation issues, and the key features of our implementation approach are presented in an accompanying paper.
CLASSIFICATION OF APPROACHES
The Ada language does not provide explicit language support for distribution.
By
D. Auty, SofTech, USA,
A. Burns, University of Bradford, UK,
C. W. McKay, University of Houston - Clear Lake, USA,
C. Randall, GHG Corporation, USA,
P. Rogers, University of Houston - Clear Lake, USA
Perhaps the greatest challenge facing Ada is in the domain of the large distributed real-time system. Because of the long lead time associated with such complex applications no real experience of the use of Ada, in this type of domain, has yet been gained. Nevertheless there are projects of a large and complex nature that are committed to the use of Ada, even though the full potential of the language has yet to prove itself in this challenging domain.
The Portable Common Execution Environment (PCEE) project is a research effort addressing the life cycle support of large, complex, non-stop, distributed computing applications with Mission And Safety Critical (MASC) components. Such applications (for example the International Space Station — Freedom) typically have extended life-time (e.g., 30 years) requirements. PCEE focuses on the system software, the interface to applications and the system architecture necessary to reliably build and maintain such systems. The requirements extend from the target system environment to the integration environment, and ultimately to the host environment. The integration environment serves as the single logical point of integration, deployment, and configuration control whereas system development occurs in the host environment. Life cycle issues include an integrated approach to the technologies (environments, tools, and methodologies) and theoretical foundations (models, principles, and concepts) that span these three environments. The scope of the effort is necessarily broad. There are, however, substantial research foundations to support development across the breadth of the project.
By
Judy M Bishop, Department of Electronics and Computer Science, The University, Southampton, England,
Michael J Hasling, Department of Electronics and Computer Science, The University, Southampton, England
Although Ada is now ten years old, there are still not firm guidelines as to how the distribution of an Ada program onto multiprocessors should be organised, specified and implemented. There is considerable effort being expended on identifying and solving problems associated with distributed Ada, and the first aim of this paper is to set out where the work is being done, and how far it has progressed to date. In addition to work of a general nature, there are now nearly ten completed distributed Ada implementations, and a second aim of the paper is to compare these briefly, using a method developed as part of the Stadium project at the University of Southampton. Much of Southampton's motivation for getting involved in distributed Ada has been the interest from the strong concurrent computing group, which has for several years taken a lead in parallel applications on transputers. The paper concludes with a classification of parallel programs and a description of how the trends in distributed Ada will affect users in the different groups.
COLLECTIVE WORK ON DISTRIBUTED ADA
The major forums where work on distributed Ada is progressing are Ada UK's International Real-Time Issues Workshop, the Ada 9X Project, SIGAda ARTEWG and AdaJUG CARTWG. Reports of these meetings appear regularly in Ada User (published quarterly by Ada UK) and Ada Letters (published bi-monthly by ACM SIGAda). The status of their activities is summarised here.
Although Ada is now reaching its adolescence, distributed Ada is still in its infancy. The extent of the problems yet to be solved and the multitude of proposed solutions presents a very real dilemma for prospective implementors and users alike. How does one specify a distributed program? What parts of Ada are allowed to be distributed? Will the underlying hardware configuration matter? Can the program be made fault tolerant and reliable in the face of processor failure? How much effort will it take to move an existing Ada program onto a mutiprocessor system? Will the proposed new Ada Standard (Ada 9X) address distributed issues?
These are just some of the questions that arise, and there is considerable effort being expended, world-wide, in answering them. However, much of this work is being conducted in small working groups, and the interim results are published only in condensed form, if at all. The aim of this book is to open the debate to as wide an audience as possible, heightening the level of awareness of the progress that has been made to date, and the issues that still remain open.
The symposium on which this book is based was held at the University of Southampton on 11–12 December 1989 and attended by nearly 100 people.
A recent trend in computer engineering has been the replacement of large uniprocessor based proprietary architectures by multiple microprocessor based designs employing various interconnection strategies. While these multiprocessor based systems offer significant performance and economic advantages over uniprocessor systems, not all prospective users are able or willing to adapt their applications to execute as multiple concurrent streams.
The Ada programming language is well suited to multiprocessor systems as it allows the programmer to direct the use of concurrency through the use of the Ada tasking mechanism. The avoidance of automatic distribution of the program by the compiler and the choice of the Ada task as the unit of distribution greatly simplify the development of Ada software for multiprocessor architectures.
For performance reasons, the inter-processor communications path should offer low latency and high transfer rates. Shared memory supports these characteristics and a multiprocessor system, where all memory can be accessed by all processors, has proven to be a suitable platform for a parallel Ada implementation.
This paper discusses the implementation and architecture of a parallel Ada system that allows up to twenty processors to co-execute the same Ada program with true concurrency. Particular attention is given to the design of the Ada runtime and the interface between the runtime and the underlying operating system, as these parts of the system must be “multi-threaded” throughout in order to minimize bottle-necks. The paper concludes with the description of a 1000 MIPS Ada engine currently under development.
By
Robert Dewar, New York University Ada/Ed Research Group,
Susan Flynn, New York University Ada/Ed Research Group,
Edmond Schonberg, New York University Ada/Ed Research Group,
Norman Shulman, New York University Ada/Ed Research Group
The Ada multi-tasking model is one in which tasks can run on separate processors and memory is either non-shared (local to one task), or shared (referenced by more than one task). It would therefore seem that mapping Ada onto a multi-processor architecture with both local and shared memory should be straightforward. This paper examines the difficulties in mapping Ada onto the IBM RP3 which is an example of such an architecture. In practice there are a number of difficult problems, the most significant of which is the inability to determine at compile time which variables are shared. The RP3 has a flexible shared memory architecture, and an important purpose of the Ada/RP3 project is to investigate possible models for implementation of Ada, with a view to determining whether modifications or enhancements of Ada are desirable to ensure optimal use of such architectures.
INTRODUCTION
The NYU Ada/Ed system consists of a front end and interpreter written entirely in C. This system is a direct descendant of the original SETL interpreter, and has been ported to a wide variety of machines [KS84].
Our current research involves porting Ada/Ed to the IBM RP3, an experimental multi-processor with shared memory [P87]. The front end is essentially unchanged, except for the addition of a set of pragmas described later, but the backend is being modified to interface with proprietary IBM code generating technology, and the runtime library is being rewritten to take advantage of the multi-processor architecture.
By
A.B. Gargaro, Computer Sciences Corporation Moorestown, New Jersey, USA,
S.J. Goldsack, Department of Computing Imperial College London, UK,
R.A. Volz, Department of Computer Science Texas A&M University, USA,
A.J. Wellings, Department of Computer Science University of York, UK
The Ada programming language was designed to provide support for a wide range of safety-critical applications within a unified language framework, but it is now commonly accepted that the language has failed to achieve all its stated design goals. A major impediment has been the lack of language support for distributed fault-tolerant program execution.
In this paper we propose language changes to Ada which will facilitate the programming of fault-tolerant distributed real-time applications. These changes support partitioning and configuration/reconfiguration. Paradigms are given to illustrate how dynamic reconfiguration of the software can be programmed following notification of processor and network failure, mode changes, software failure, and deadline failure.
INTRODUCTION
There is increasing use of computers that are embedded in some wider engineering application. These systems all have several common characteristics: they must respond to externally generated input stimuli within a finite and specified period; they must be extremely reliable and/or safe; they are often geographically distributed over both a local and a wide area; they may contain a very large and complex software component; they may contain processing elements which are subject to cost/size/weight constraints.
Developing software to control safety-critical applications requires programming abstractions that are unavailable in many of today's programming languages. The Ada programming language was designed to provide support for such applications within a unified language framework, but it is now commonly accepted that the language has failed to achieve all its stated design goals.
By
Colin Atkinson, Imperial College, Dept. of Computing, 180 Queens Gate, London SWZ 2BZ, U.K.,
Andrea Di Maio, TXT S.p.A, Via Socrate, 41, 20128 Milano, Italy.
Although the introduction of Ada represented a significant step forward for the developers and users of embedded systems, experience in the use of the language has demonstrated that it has several shortcomings, particularly in the realm of distributed systems. Some of the difficulties with Ada in this respect are caused by relatively minor semantic details chosen without due regard for the properties of distributed systems, such as the semantics of timed and conditional entry calls, and should be easily rectified. Others, however, are of a much more fundamental nature, and are likely to require more significant modifications to the language to overcome them.
One of the main problems of the existing version of Ada is its execution model, based on the notion of a single main program. This model does not carry over well to distributed environments, and tends to reduce the prospects for supporting dynamic configuration and flexible responses to hardware failure.
The purpose of this paper is to outline the difficulties caused by the current execution model of Ada, and to describe the different solutions devised by the European projects, DIADEM, and DRAGON. The first of these was a small project partially funded under the Multi-Annual Programme of the Commission of the European communities, and was completed early in 1987. The second project is partially supported under the Esprit program of the Commission, and is due for completion in the middle of 1990.