Sandeep Mitra

Priority inversion in Ada programs during elaboration

Priority inversion is any situation where low priority tasks are served before higher priority tasks. It is recognized as a serious problem for real-time systems. We have observed priority inversion due to the elaboration order in versions of AIsys I Ada and VAX ~ Ada. This paper presents a rigorous description of Alsys Adas priority inversion during elaboration of library packages; this behavior is specified in a semi-formal partial model of the elaboration algorithm of the Alsys 286 DOS Ada Compiler V4.2, running under PC-DOS Version 3.30 on an IBM PC AT. s The model was deduced from a series of experiments designed to illuminate the full scheduling features of the system. These results may provide useful insight for users of this and other Ada compilers. Similar priority inversion was also observed for VAX Ada running under VMS. K e y w o r d s : Ada, Alsys, context clauses, elaboration, performance model, priority, priority inversion, reverse engineering, simulation, task scheduling I Alsys is a registered trademark of Alsys z VAX and VMS are trademarks of Digital Equipment Corporation IBM, PC AT and PC-DOS are registered trademarks of International Business Machines Corporation COPYRIGHT 1990 BY THE ASSOCIATION FOR COMPUTING MACHINERY, INC. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and or specific permission. In [9] priority inversion is defined to be any situation where a low priority task holds a resource while a higher priority task is ready to use it. In [4] and [5], the definition of priority inversion, attributed to Lui Sha, is given as any situation where low priority tasks are served before higher priority tasks. Priority inversion is recognized as a serious problem for real-time systems [4]. Priority inversion during the execution of an Ada program may occur in a number of situations, including: In a rendezvous when the accept code is being executed by or on behalf of a low priority task while, after rescheduling, it might be executed by or on behalf of a higher priority task, which is blocked, see, for example, [4]. This inversion is permitted and in many cases forced by the Ads semantics [1] and occurs because of the combination of the sequence of task execution and the structure of the program. Priority inversion may occur in selective wait statements where a high priority task at the head of one entry queue is ignored while a low priority task at the head of another entry queue is accepted. Such inversion is permitted but not forced by the Ada semantics [2]. We report elsewhere [8] that this form of inversion may result from applying a deterministic rather than a random selection algorithm. We have recognized a form of priority inversion during the elaboration of Ada programs with the two Ada compilers we have used. Tasks of low priority are served first by the CPU because high priority tasks have not yet been elaborated. Ada semantics would appear to state that, at the beginning of program execution, the highcst priority tasks should run first. However the tasks in a package may begin to run as soon as that package is elaborated. If the lowest priority tasks are in the first package to be elaborated, they will run first. Our observation occurred during experiments of wider scope described below. The work presented in this paper constitutes a portion of a Wash ing ton Ada S y m p o s i u m P r o c e e d i n g s . June 1990 133 larger project in formal system specification methodologies and performance prediction being carried out in the Department of Computer Science at SUNY Binghamton. As a performance measurement and validation vehicle we are building a Communications Gateway [11, 12] which will multiplex several IBM Token Ring LAN users to the DataSwitch of the SUNY-Binghamton Computer Center. The primary purpose ofthc Gateway is to provide an instrumented multi-tasked Ada system whose actual performance will be compared to that predicted via analysis of specification models of the system (see [3]). The Gateway code will be compiled in Alsys Ada and will run in the Alsys run-time environment. In order to develop a detailed performance model [13] (in our case to be used for simulation analysis of the Gateway behavior), we shall incorporate into the model the activity scheduling algorithm associated with the Alsys compilation process and the execution logic of the Alsys run-time environment. Since the Alsys scheduling algorithm involves proprietary information which was unavailable to us, reverse engineering experiments have been undertaken to deduce a plausibly defensible model for the Alsys scheduling algorithm. We are using controlled experimental probe Ada programs running in the Alsys environment. This document presents results pertaining to the elaboration phase of multi-package Ada programs. Complete reports [6, 14] on the work to date are available from the authors.

Detection and Avoidance of Elaboration-Time Problems for Multi-Unit Real-Time Ada Applications

This paper describes three significant problems that may occur due to the elaboration order of the compilation units of a large Ada program. One concern is the possibility of access-before-elaboration errors. A second issue is priority inversion amongst library tasks—a possibly serious problem for real-time systems, for example, in the implementation of the Priority Ceiling Protocol. A third problem is elaboration-time deadlock—the situation where elaboration cannot be completed because a non-task entity calls a task entry before the activation of the task. In this paper we outline a set of coding practices which, if rigorously followed, eliminate most elaboration-time problems. Also, we briefly describe a scheme to determine a proper elaboration order on the basis of source code analysis and show how such a scheme can be used, if our coding practices are followed, to detect potential elaboration-time deadlock situations.

Specification and automated implementation of coordination protocols in distributed controls for flexible manufacturing cells

This paper describes a new specification model called the dynamic coordinated concurrent activities (DCCA) model and shows its utility for the specification of coordination protocols needed in manufacturing control systems. The principal advantage of this model lies in the ease with which a distributed implementation of the specified controls may be automatically generated from the formal specification itself in this paper, the authors describe some specific DCCA features, such as dynamic processes, structured states and a versatile means of specifying predicates on such states- these features facilitate obtaining a largely generic and reusable specification of a real-world FMC. The authors emphasize the elegant methodology for obtaining the distributed implementation automatically.<<ETX>>

The elaboration order problem of Ada

A serious problem in large Ada programs is finding a satisfactory order of elaboration for all of the programs compilation units. Some elaboration sequence must be selected but access to a program entity before its elaboration will raise the exception (PROGRAM_ERROR) shortly after execution of the program begins. The rules of the 1983 Ada standard1 fail to ensure that validated compilers produce a satisfactory elaboration order, or report an error if static analysis shows that such an order may not exist. The problem can make programs non‐portable and sensitive to modifications. This paper presents an algorithm ada_elab which determines an order of elaboration, free of PROGRAM_ERROR, if link‐time, static analysis can determine that there is one. Examples are used to illustrate the occurrence of elaboration errors and the inadequacy of pragma ELABORATE to resolve the problem. The paper closes with descriptions of elaboration and elaboration‐related problems that cannot be handled by ada_elab, access before initialization and coding practices that should avoid elaboration and initialization errors. While Ada is the subject of this paper, the problem being studied could occur in any language that permits a complex initialization of individual program modules prior to the execution of the main program module.

Infrastructure for the synchronization and coordination of concurrent Java component programs

The paper presents the Development Environment for Coordinated Concurrent Activities (DECCA), a system incorporating a methodology and toolkit for developing concurrent, coordinating systems in a high-level, component oriented, reusable manner. A unique feature of DECCA is that it provides a Java API that enables behavior descriptions to be made using Javas conventional and OOP features, thus facilitating great flexibility in the description without compromising the methodologys high level features and component oriented nature. The paper presents the salient features of the DECCA methodology and infrastructure through illustrative examples. The difficulty in obtaining component based, reusable descriptions in the absence of such a methodology is also described. Finally, a comparison of DECCA with similar systems is presented.

Techniques for semi-automated implementation of state-oriented, real-time formal specifications in Ada

This paper describes salient features of a formal spedlcdon technique called State Architecture Notation (SAN), that is @cularly suited to the specification of functional properties as welI as Concurrency/real-time aspcta of large soflware. The issues involved in automatically mmsladng SAN specifications into Ada programs are discussed in this paper. Finally, we present our experiences with a spwiilc application of this specificatiodiiplement.ation process to a conventional realtime scheduling technique.