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:

   • It was considered during the Ada 83 design but rejected on the grounds that most programmers would lazily specify "raise anything" rather than detail all the possible exceptions that might be propagated.
   • Java takes a compromise approach, distinguishing "checked" from "unchecked" exceptions, but it has some loopholes since e.g. via the intraspection facility a method may throw an arbitrary exception regardless of its "throws" clause.

   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:

   • Simple syntax for unchecked conversion

     The subset compiler does not have generics, and achieving the effect of an unchecked conversion (via address clauses) is claimed to be somewhat clumsy. An attribute would be a lighter-weight notation to achieve this sometimes-needed functionality.

     The opposing argument is that the heavyweight syntax is there by intent, in order to discourage its casual use and to make it clear (by the presence of a with clause identifying the potentially-unsafe feature) when it is being used.

   • Ability to mark a variable as "readonly"

     In many abstractions, hidden state is accessed by a query function. Although in principle the function overhead can be avoided by specifying pragma Inline, in practice there may still be some run-time penalty. The ability to specify that a client's view on a variable is readonly would solve this problem since there would be no need to define a query function.

   • Shift/rotate for unsigned types in general

     Although shift and rotate functions are provided for the unsigned types in package Interfaces, it would be useful if they were available more generally for user-defined unsigned types as well.

     The opposing argument is that such a facility might have a major impact on implementations, since no other type declaration introduces functions (other than operator symbols) for the new type.