Go to the first, previous, next, last section, table of contents.
-
This clause specifies representation pragmas that control the use of
shared variables.
Syntax
-
The form for pragmas Atomic, Volatile, Atomic_Components, and
Volatile_Components is as follows:
-
pragma Atomic(local_name);
-
pragma Volatile(local_name);
-
pragma Atomic_Components(array_local_name);
-
pragma Volatile_Components(array_local_name);
-
An atomic type is one to which a pragma Atomic applies. An atomic object
(including a component) is one to which a pragma Atomic applies, or a
component of an array to which a pragma Atomic_Components applies, or
any object of an atomic type.
-
A volatile type is one to which a pragma Volatile applies. A volatile
object (including a component) is one to which a pragma Volatile
applies, or a component of an array to which a pragma
Volatile_Components applies, or any object of a volatile type. In
addition, every atomic type or object is also defined to be volatile.
Finally, if an object is volatile, then so are all of its subcomponents
(the same does not apply to atomic).
Name Resolution Rules
-
The local_name in an Atomic or Volatile pragma shall resolve to denote
either an object_declaration, a non-inherited component_declaration, or
a full_type_declaration. The array_local_name in an Atomic_Components or
Volatile_Components pragma shall resolve to denote the declaration of an
array type or an array object of an anonymous type.
Legality Rules
-
It is illegal to apply either an Atomic or Atomic_Components pragma to
an object or type if the implementation cannot support the indivisible
reads and updates required by the pragma (see below).
-
It is illegal to specify the Size attribute of an atomic object, the
Component_Size attribute for an array type with atomic components, or
the layout attributes of an atomic component, in a way that prevents the
implementation from performing the required indivisible reads and
updates.
-
If an atomic object is passed as a parameter, then the type of the
formal parameter shall either be atomic or allow pass by copy (that is,
not be a nonatomic by-reference type). If an atomic object is used as an
actual for a generic formal object of mode in out, then the type of the
generic formal object shall be atomic. If the prefix of an
attribute_reference for an Access attribute denotes an atomic object
(including a component), then the designated type of the resulting
access type shall be atomic. If an atomic type is used as an actual for
a generic formal derived type, then the ancestor of the formal type
shall be atomic or allow pass by copy. Corresponding rules apply to
volatile objects and types.
-
If a pragma Volatile, Volatile_Components, Atomic, or Atomic_Components
applies to a stand-alone constant object, then a pragma Import shall
also apply to it.
Static Semantics
-
These pragmas are representation pragmas, See section 13.1 Representation Items.
Dynamic Semantics
-
For an atomic object (including an atomic component) all reads and
updates of the object as a whole are indivisible.
-
For a volatile object all reads and updates of the object as a whole are
performed directly to memory.
-
Two actions are sequential, See section 9.10 Shared Variables, if each is the read or update
of the same atomic object.
-
If a type is atomic or volatile and it is not a by-copy type, then the
type is defined to be a by-reference type. If any subcomponent of a type
is atomic or volatile, then the type is defined to be a by-reference
type.
-
If an actual parameter is atomic or volatile, and the corresponding
formal parameter is not, then the parameter is passed by copy.
Implementation Requirements
-
The external effect of a program, See section 1.1.3 Conformity of an Implementation with the Standard, is defined to include
each read and update of a volatile or atomic object. The implementation
shall not generate any memory reads or updates of atomic or volatile
objects other than those specified by the program.
-
If a pragma Pack applies to a type any of whose subcomponents are
atomic, the implementation shall not pack the atomic subcomponents more
tightly than that for which it can support indivisible reads and
updates.
NOTES
-
(9) An imported volatile or atomic constant behaves as a constant (i.e.
read-only) with respect to other parts of the Ada program, but can still
be modified by an "external source."
Go to the first, previous, next, last section, table of contents.