System design with Ada
Concurrent programming in Ada
Some problems in distributing real-time Ada programs across machines
SIGAda '85 Proceedings of the 1985 annual ACM SIGAda international conference on Ada
Using Ada and Apse to support distributed multimicroprocessor targets
ACM SIGAda Ada Letters
| Hi-index | 0.00 |
All the problems associated with concurrency in any language are troublesome when using Ada*: deadlock, critical access, race conditions, starvation, abnormal termination and timing errors. In addition, however, programmers in Ada must deal with difficulties presented by the Ada tasking model. This investigation is an attempt to summarize difficulties encountered in an industrial project and others described in the literature:A passive task must include a terminate alternative or it will not terminate naturally.An active task must be artificially delayed or it will continue indefinitely, delaying all other tasks.Even if an active task is delayed, the context switch may take longer than the delay, causing the original task to be swapped back in. If the delay is too long, however, a situation could be created where all tasks are delayed.Both active and passive tasks may poll and thus never rendezvous.Context switch involves tremendous overhead. Is the model to blame or machine design?Parallel distribution of parameters to a collection of tasks can cause a serial bottleneck.Entry calls are serviced in a queue. No attempt is made to service higher priority tasks first.The use of shared variables can lead to unexpected results.In a distributed environment timed entry calls and conditional entry calls may have unexpected behavior.The abort statement does not really terminate a task.There is no way to assign tasks (or anything) to processors. What is to be distributed and how?There are some “Tips” for solving some of these “Troubles” but some of the difficulties cannot be solved easily. In the Nassi-Habermann paper a method for solving some problems consists of removing the tasks entirely.