![[Ada Information Clearinghouse]](small_adaic_logo.gif)
Ada '83 Quality and Style:
Guidelines for Professional Programmers
CHAPTER 7: Portability
The definition of tasking in the Ada language leaves many characteristics of
the tasking model up to the implementor. This allows a vendor to make
appropriate tradeoffs for the intended application domain, but it also
diminishes the portability of designs and code employing the tasking features.
In some respects this diminished portability is an inherent characteristic of
concurrency approaches (see Nissen and Wallis 1984, 37).
A discussion of Ada tasking dependencies when employed in a distributed target
environment is beyond the scope of this book. For example, multi-processor task
scheduling, interprocessor rendezvous, and the distributed sense of time
through package Calendar are all subject to differences between
implementations. For more information, Nissen and Wallis (1984) and ARTEWG
(1986) touch on these issues and (Volz et al. 1985) is one of many research
articles available.
Language Ref Manual references:
9 Tasks
guideline
- Do not depend on the order in which task objects are activated when
declared in the same declarative list.
rationale
The order is left undefined in the Ada Language Reference Manual (Department
of Defense 1983).
Language Ref Manual references:
9.3 Task Execution - Task Activation
guideline
- Do not depend on a particular delay being achievable (Nissen and
Wallis 1984).
- Never use a busy waiting loop instead of a delay.
- Design to limit polling to those cases where it is absolutely
necessary.
- Never use knowledge of the execution pattern of tasks to achieve
timing requirements.
rationale
The rationale for this appears in
Guideline 6.1.5.
In addition, the treatment of
delay statements varies from implementation to implementation thereby
hindering portability.
Language Ref Manual references:
5.5 Loop Statements,
9.3 Task Execution - Task Activation,
9.6 Delay Statements, Duration, and Time
guideline
- Do not assume a correlation between
System.Tick
and package Calendar or type Duration
(see Guideline 6.1.5).
rationale
Such a correlation is not required, although it may exist in some
implementations.
Language Ref Manual references:
9.6 Delay Statements, Duration, and Time,
13.7.1 System-Dependent Named Numbers,
F Implementation-Dependent Characteristics
guideline
- Do not depend on the order in which guard conditions are evaluated or
on the algorithm for choosing among several open select alternatives.
rationale
The language does not define the order of these conditions, so assume that
they are arbitrary.
Language Ref Manual references:
9.7.1 Selective Waits
guideline
- Do not assume that tasks execute uninterrupted until they reach a
synchronization point.
- Use pragma
Priority to distinguish general levels of importance only
(see Guideline 6.1.4).
rationale
The Ada tasking model requires that tasks be synchronized only through the
explicit means provided in the language (i.e., rendezvous, task dependence,
pragma Shared). The scheduling algorithm is not defined by the language and
may vary from time sliced to preemptive priority. Some implementations (e.g.,
VAX Ada) provide several choices that a user may select for the application.
note
The number of priorities may vary between implementations. In addition, the
manner in which tasks of the same priority are handled may vary between
implementations even if the implementations use the same general scheduling
algorithm.
exceptions
In real-time systems it is often necessary to tightly control the tasking
algorithm to obtain the required performance. For example, avionics systems
are frequently driven by cyclic events with limited asynchronous
interruptions. A nonpreemptive tasking model is traditionally used to obtain
the greatest performance in these applications. Cyclic executives can be
programmed in Ada, as can a progression of scheduling schemes from cyclic
through multiple-frame-rate to full asynchrony (MacLaren 1980) although an
external clock is usually required.
Language Ref Manual references:
9.3 Task Execution - Task Activation,
9.5 Entries, Entry Calls, and Accept Statements,
9.8 Priorities,
B Predefined Language Pragmas
guideline
- Avoid using the abort statement.
rationale
The rationale for this appears in
Guideline 6.3.3. In addition, treatment of the
abort statement varies from implementation to implementation thereby hindering
portability.
Language Ref Manual references:
9.1 Abort Statements
guideline
- Do not share variables.
- Have tasks communicate through the rendezvous mechanism.
- Do not use shared variables as a task synchronization device.
- Use pragma Shared only when you are forced to by run time system
deficiencies.
rationale
The rationale for this appears in Guideline
6.2.4. In addition, the treatment of
shared variables varies from implementation to implementation thereby
hindering portability.
Language Ref Manual references:
9.5 Entries, Entry Calls, and Accept Statements,
9.11 Shared Variables,
B Predefined Language Pragmas
Back to document index