Summary of IRONMASCC Task
I Really Only Need Mission And Safety Critical Computing

Session Leader: Erhard Ploedereder

Scribe: Ben Brosgol

The session was organized as a general open discussion of several topics.

  1. CPU accounting

    Per-task time is perennially a feature that users want/need; the issue seems more a question of how (rather than whether) it should be realized. A "magic" API is one approach, but a TCB attribute is perhaps more natural.

    Applications include user-defined scheduling and also enforcement of execution time budgets in Rate Monotonic Scheduling.

  2. What to do about distribution

    There was a question of how time is managed in a distributed system. Having only one clock means a single point of failure; having many clocks means that they must be kept in synch. It was pointed out that in practice fault tolerance requires multiple clocks, and that the synchronization problem, though hard, is solvable.

    One user indicated that he preferred the Distribution Annex over CORBA since it seemed to give him lower-level facilities that he needed.

    The Distribution Annex seems not to be used heavily; one reason is that it models a distributed Ada program whereas in practice the need is for distributing mixed-language programs.

    Should the Distribution Annex be removed from the Standard? Probably not, although for nontechnical rather than technical reasons.

    There was a request to formalize an Ada interface to CORBA.

    Several users reported positive experience with Ada in tightly-coupled (shared-memory, multiprocessor) environments. It is interesting that so-called "memory model" issues (relating to optimizations in a tasking program) have not arisen in Ada, whereas they are attracting considerable discussion in Java.

  3. What is desired in the area of safety and security

    A standardized set of restrictions and predefined profiles is needed. Indeed, that is the path being taken by the ARG.

    Perhaps more flexibly, having various user-selectable stylistic rules enforced by the compiler would be nice. An ASIS tool could presumably do the necessary analysis.

    An assertion facility is important. There are two kinds: a dynamic mechanism, which evaluates a Boolean expression and raises an exception if the expression is False, and a static mechanism, which involves quantification and predicate logic and which supports "design by contract". The dynamic model is much simpler to specify and implement than the static model. The current AI on the subject seems to be a mixture of the two approaches and is asserted to have some problems.

    It would be nice if the "physical units" problem had a reasonable (and compile-time) solution in Ada.

    Should Ada introduce a facility for requiring a subprogram to identify the exceptions that it can propagate? Aside from the compatibility problems, there are several issues with such a feature:

    To support security requirements, it would be useful to have a mechanism (e.g. a pragma) that would zero out (or otherwise erase the contents of) the released memory when an object is deallocated or the stack is popped.

  4. Miscellaneous

    One user indicated the desire for several features to support the qualified Ada subset compiler that was described in one of the papers: