Contents Index Search Previous Next
10.2 Program Execution
1
An
Ada
program consists of a set of
partitions, which can
execute in parallel with one another, possibly in a separate address
space, and possibly on a separate computer.
Post-Compilation Rules
2
A partition
is a program or part of a program that can be invoked from outside the
Ada implementation. For example, on many systems, a partition might be
an executable file generated by the system linker.
The
user can
explicitly assign library units to a partition. The assignment
is done in an implementation-defined manner. The compilation units included
in a partition are those of the explicitly assigned library units, as
well as other compilation units
needed by those library units.
The compilation units needed by a given compilation unit are determined
as follows (unless specified otherwise via an implementation-defined
pragma, or by some other implementation-defined
means):
3
- A compilation unit needs itself;
4
- If a compilation unit is needed, then
so are any compilation units upon which it depends semantically;
5
- If a library_unit_declaration
is needed, then so is any corresponding library_unit_body;
6
- If a compilation unit with stubs is
needed, then so are any corresponding subunits.
7
The user can optionally designate
(in an implementation-defined manner) one subprogram as the
main subprogram
for the partition. A main subprogram, if specified, shall be a subprogram.
8
Each partition has an anonymous
environment task, which is an implicit outermost task whose execution
elaborates the
library_items of
the environment
declarative_part,
and then calls the main subprogram, if there is one. A partition's execution
is that of its tasks.
9
The order of elaboration of library units is determined
primarily by the
elaboration dependences.
There
is an elaboration dependence of a given
library_item
upon another if the given
library_item
or any of its subunits depends semantically on the other
library_item.
In addition, if a given
library_item
or any of its subunits has a
pragma
Elaborate or Elaborate_All that mentions another library unit, then there
is an elaboration dependence of the given
library_item
upon the body of the other library unit, and, for Elaborate_All only,
upon each
library_item needed by
the declaration of the other library unit.
10
The environment
task for a partition has the following structure:
11
task Environment_Task;
12
task body Environment_Task is
... (1) -- The environment declarative_part
-- (that is, the sequence of library_items) goes here.
begin
... (2) -- Call the main subprogram, if there is one.
end Environment_Task;
13
The
environment
declarative_part at
(1) is a sequence of
declarative_items
consisting of copies of the
library_items
included in the partition. The order of elaboration of
library_items
is the order in which they appear in the environment
declarative_part:
14
- The order of all included library_items
is such that there are no forward elaboration dependences.
15
- Any included library_unit_declaration
to which a pragma Elaborate_Body
applies is immediately followed by its library_unit_body,
if included.
16
- All library_items
declared pure occur before any that are not declared pure.
17
- All preelaborated library_items
occur before any that are not preelaborated.
18
There shall be a total order of the library_items
that obeys the above rules. The order is otherwise implementation defined.
19
The full expanded names of the library units
and subunits included in a given partition shall be distinct.
20
The sequence_of_statements
of the environment task (see (2) above) consists of either:
21
- A call to the main subprogram, if
the partition has one. If the main subprogram has parameters, they are
passed; where the actuals come from is implementation defined. What happens
to the result of a main function is also implementation defined.
22
or:
23
- A null_statement,
if there is no main subprogram.
24
The mechanisms for building and running partitions
are implementation defined. These might be combined into one operation,
as, for example, in dynamic linking, or ``load-and-go'' systems.
Dynamic Semantics
25
The execution of a program
consists of the execution of a set of partitions. Further details are
implementation defined.
The execution of a partition
starts with the execution of its environment task, ends when the environment
task terminates, and includes the executions of all tasks of the partition.
The execution of the (implicit)
task_body
of the environment task acts as a master for all other tasks created
as part of the execution of the partition. When the environment task
completes (normally or abnormally), it waits for the termination of all
such tasks, and then finalizes any remaining objects of the partition.
Bounded (Run-Time) Errors
26
Once
the environment task has awaited the termination of all other tasks of
the partition, any further attempt to create a task (during finalization)
is a bounded error, and may result in the raising of Program_Error either
upon creation or activation of the task.
If such
a task is activated, it is not specified whether the task is awaited
prior to termination of the environment task.
Implementation Requirements
27
The implementation
shall ensure that all compilation units included in a partition are consistent
with one another, and are legal according to the rules of the language.
Implementation Permissions
28
The kind of partition described
in this clause is known as an
active partition. An implementation
is allowed to support other kinds of partitions, with implementation-defined
semantics.
29
An implementation may restrict the kinds of subprograms
it supports as main subprograms. However, an implementation is required
to support all main subprograms that are public parameterless library
procedures.
30
If the environment task completes abnormally,
the implementation may abort any dependent tasks.
31
8 An implementation may
provide inter-partition communication mechanism(s) via special packages
and pragmas. Standard pragmas for distribution and methods for specifying
inter-partition communication are defined in Annex
E, ``Distributed Systems''. If no such mechanisms
are provided, then each partition is isolated from all others, and behaves
as a program in and of itself.
32
9 Partitions are not required
to run in separate address spaces. For example, an implementation might
support dynamic linking via the partition concept.
33
10 An order of elaboration
of library_items that is consistent
with the partial ordering defined above does not always ensure that each
library_unit_body is elaborated
before any other compilation unit whose elaboration necessitates that
the library_unit_body be already
elaborated. (In particular, there is no requirement that the body of
a library unit be elaborated as soon as possible after the library_unit_declaration
is elaborated, unless the pragmas in subclause 10.2.1
are used.)
34
11 A partition (active
or otherwise) need not have a main subprogram. In such a case, all the
work done by the partition would be done by elaboration of various library_items,
and by tasks created by that elaboration. Passive partitions, which cannot
have main subprograms, are defined in Annex E,
``Distributed Systems''.
Contents Index Search Previous Next Legal