Conclusions
7.2 Future Work
7.2 Future Work
The most immediately useful and important area for future research is the completion of the formal denition of Ada tasking in TSL. This can be accomplished through straightforward application of the principles described in Chapter 6.
There are also proposals for using the Distributed Ada Supervisor in the implementa- tion of the formal specication languages being developed by the Program Analysis and Verication Group of the Computer Systems Laboratory at Stanford University. All of the proposals are directed toward reducing the interference of specication checking on the ex- ecution of application programs during runtime checking. In particular, the Supervisor will be used to implement automatic runtime checking of Anna specications in parallel with the execution of the program whose behavior is being checked RSL86]. It will also be used to build a distributed implementation of TSL integration of the TSL Runtime System with the Supervisor would also simplify the generation of TSL events at runtime. Finally, VAL (VHDL Annotation Language) is being developed for the formal specication of VHDL hardware designs AGH*87] the Supervisor will be used for parallel design simulation and for checking the consistency of a simulated design with its VAL specication.
Other areas for future work in the short term include the completion of the Supervisor design to handle the unimplemented features of Ada tasking. A more general area for future work in the long term is the development of new paradigms for modeling concurrency. Both these areas are discussed in detail below.
7.2.1 Remaining Ada Supervisor Design Details
As was mentioned in Chapter 4, there are a few features of Ada tasking that are unaccounted for in the design of the Distributed Ada Supervisor. Implementation of these features would make the Supervisor more useful for real-time programs and other specialized concurrent software applications. Additionally, a realistic scheme must be incorporated into the Su- pervisor design for partitioning a program for ecient distributed execution. Ideally, the chosen scheme would divide the burden of partitioning between the compiler and the Super- visor. Several partitioning algorithms, both static and dynamic, have been proposed (e.g., Sarkar and Hennessy SH86]). In addition, the Supervisor could be enhanced to support dy- namic migration of tasks between processors the enhancements described in Ros87] would be required along with some atomic state update algorithms such as the ones described by
Theimer et al. TLC85].
The implementation of task priorities requires that the Supervisor have the capability to pre empt and time-slice task executions. The implementation of time-slicing requires the handling of asynchronous interrupts from timer hardware. As Ada compilers become more exible, the incorporation of the necessary interrupt handlers into the Supervisor scheduler should be less of a problem than it was using the VERDIX compiler.
The compilation of rendezvous parameters for message-passing must eciently handle all types of parameter values, including limited types. A more ecient scheme of parameter passing than the one described in Appendix E would use the facilities of an operating system that oers good distributed memory copying features, such as the V System.
Appendix E also outlined some algorithms for compiling some of the more dicult con- gurations of Ada selective waits, such as selective waits with multiple
accept
statements for the same entry or with multipledelay
alternatives. Since the Supervisor allows at most oneaccept
alternative per task entry and at most onedelay
alternative to be considered during execution of a selective wait, the compiled application program must choose a single alternative before calling the ACCEPT BEGIN procedure. Thus, compilation of selective waits must take these special cases into account in a suitable fashion.The message-passing protocol of the Supervisor supports the propagation of exceptions between tasks. However, no general transformations were given in Appendix E for catching an exception that is raised in the middle of a rendezvous and passing it to the calling task. The Supervisor currently only propagates TASKING ERROR when an entry call is placed to a completed, terminated or abnormal task, and upon unsuccessful activation of a dependent task. Since Ada provides no general source-level facility for determining the name of an arbitrary propagated exception, exceptions and exception handlers must be compiled into simpler sequential constructs so that a general exception propagation facility can be incorporated into the Supervisor. Techniques described in BR86] would be useful for this purpose.
Finally, the remaining unimplemented portion of the Ada tasking semantics is the man- agement of shared global variables. Ada discourages the use of global variables for intertask communication, and indeed the semantics of shared variables in Ada are very weak. How- ever, a minimum standard of behavior of shared variables is specied by the Ada Language Reference Manual and is required of all implementations. And despite Ada's discourage- ment of the use of shared global variables, programmers will nevertheless use them when
7.2. FUTURE WORK 137