9.10 Shared Variables
If two different objects, including
nonoverlapping parts of the same object, are independently addressable
they can be manipulated concurrently by two different tasks without synchronization.
Any two nonoverlapping objects are independently
addressable if either object is specified as independently addressable
(see C.6). Otherwise, two nonoverlapping objects
are independently addressable except when they are both parts of a composite
object for which a nonconfirming value is specified for any of the following
representation aspects: (record) Layout, Component_Size, Pack, Atomic,
or Convention; in this case it is unspecified whether the parts are independently
any two nonoverlapping objects are independently addressable. However,
if packing, record layout, or Component_Size is specified for a given
composite object, then it is implementation defined whether or not two
nonoverlapping parts of that composite object are independently addressable.
was deleted.Implementation defined:
Whether or not two nonoverlapping parts
of a composite object are independently addressable, in the case where
packing, record layout, or Component_Size is specified for the object.
Independent addressability is the only high level semantic effect of
aspect a pragma
Pack. If two objects are independently addressable, the implementation
should allocate them in such a way that each can be written by the hardware
without writing the other. For example, unless the user asks for it,
it is generally not feasible to choose a bit-packed representation on
a machine without an atomic bit field insertion instruction, because
there might be tasks that update neighboring subcomponents concurrently,
and locking operations on all subcomponents is generally not a good idea.
Even if Pack packing
or one of the other above-mentioned aspects is specified, subcomponents
should still be updated independently if the hardware efficiently supports
An atomic object (including atomic components)
is always independently addressable from any other nonoverlapping object.
or representation item which would prevent this from being true should
be rejected, notwithstanding what this Standard says elsewhere. Note,
however, that the components of an atomic object are not necessarily
[Separate tasks normally
proceed independently and concurrently with one another. However, task
interactions can be used to synchronize the actions of two or more tasks
to allow, for example, meaningful communication by the direct updating
and reading of variables shared between the tasks.] The actions of two
different tasks are synchronized in this sense when an action of one
an action of the other task;
action A1 is defined to signal an action A2 under the following circumstances:
If A1 and A2 are part of the execution of the same
task, and the language rules require A1 to be performed before A2;
If A1 is the action of an activator that initiates
the activation of a task, and A2 is part of the execution of the task
that is activated;
If A1 is part of the activation of a task, and
A2 is the action of waiting for completion of the activation;
If A1 is part of the execution of a task, and A2
is the action of waiting for the termination of the task;
If A1 is the termination of a task T, and A2 is
either an the evaluation of the expression T'Terminated that results in True, or a call to Ada.Task_Identification.Is_Terminated
with an actual parameter that identifies T and
a result of True (see C.7.1);
If A1 is part of the execution of an accept_statement
and A2 is the action of returning from the corresponding entry call;
If A1 is part of the execution of a protected procedure
body or entry_body
for a given protected object, and A2 is part of a later execution of
for the same protected object;
Reason: The underlying principle here
is that for one action to “signal” a second, the second action
has to follow a potentially blocking operation, whose blocking is dependent
on the first action in some way. Protected procedures are not potentially
blocking, so they can only be "signalers," they cannot be signaled.
Ramification: Protected subprogram calls
are not defined to signal one another, which means that such calls alone
cannot be used to synchronize access to shared data outside of a protected
Reason: The point of this distinction
is so that on multiprocessors with inconsistent caches, the caches only
need to be refreshed at the beginning of an entry body, and forced out
at the end of an entry body or protected procedure that leaves an entry
open. Protected function calls, and protected subprogram calls for entryless
protected objects do not require full cache consistency. Entryless protected
objects are intended to be treated roughly like atomic objects —
each operation is indivisible with respect to other operations (unless
both are reads), but such operations cannot be used to synchronize access
to other nonvolatile shared variables.
If A1 signals some
action that in turn signals A2.
an action of assigning to an object, and an action of reading or updating
a part of the same object (or of a neighboring object if the two are
not independently addressable), then the execution of the actions is
erroneous unless the actions are sequential
actions are sequential if one of the following is true:
One action signals the other;
Both actions occur as part of the execution of
the same task;
Reason: Any two actions of the same task
are sequential, even if one does not signal the other because they can
be executed in an “arbitrary” (but necessarily equivalent
to some “sequential”) order.
Both actions occur as part of protected actions
on the same protected object, and at most one of the actions is part
of a call on a protected function of the protected object.
Reason: Because actions within protected
actions do not always imply signaling, we have to mention them here explicitly
to make sure that actions occurring within different protected actions
of the same protected object are sequential with respect to one another
(unless both are part of calls on protected functions).
Ramification: It doesn't matter whether
or not the variable being assigned is actually a subcomponent of the
protected object; globals can be safely updated from within the bodies
of protected procedures or entries.
Aspect A pragma
Atomic or aspect
Atomic_Components may also
be specified used
to ensure that certain reads and updates are sequential — see C.6
Ramification: If two actions are “sequential”
it is known that their executions don't overlap in time, but it is not
necessarily specified which occurs first. For example, all actions of
a single task are sequential, even though the exact order of execution
is not fully specified for all constructs.
Discussion: Note that if two assignments
to the same variable are sequential, but neither signals the other, then
the program is not erroneous, but it is not specified which assignment
ultimately prevails. Such a situation usually corresponds to a programming
mistake, but in some (rare) cases, the order makes no difference, and
for this reason this situation is not considered erroneous nor even a
bounded error. In Ada 83, this was considered an “incorrect order
dependence” if the “effect” of the program was affected,
but “effect” was never fully defined. In Ada 95, this situation
represents a potential nonportability, and a friendly compiler might
want to warn the programmer about the situation, but it is not considered
an error. An example where this would come up would be in gathering statistics
as part of referencing some information, where the assignments associated
with statistics gathering don't need to be ordered since they are just
accumulating aggregate counts, sums, products, etc.
Wording Changes from Ada 95
Corrigendum: Clarified that a task T2 can
rely on values of variables that are updated by another task T1, if task
T2 first verifies that T1'Terminated is True.
Wording Changes from Ada 2005
Correction: Revised the definition of independent
addressability to exclude conforming representation clauses and to require
that atomic and independent objects always have independent addressability.
This should not change behavior that the user sees for any Ada program,
so it is not an inconsistency.
Correction: Corrected the wording of AI95-00118-01
to actually say what was intended (as described above).
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe