E.2.1 Shared Passive Library Units
1
[A shared passive library unit is used for managing
global data shared between active partitions. The restrictions on shared
passive library units prevent the data or tasks of one active partition
from being accessible to another active partition through references
implicit in objects declared in the shared passive library unit.]
Language Design Principles
1.a
The restrictions governing a shared passive
library unit are designed to ensure that objects and subprograms declared
in the package can be used safely from multiple active partitions, even
though the active partitions live in different address spaces, and have
separate run-time systems.
Syntax
2
The
form of a
pragma
Shared_Passive is as follows:
3
pragma Shared_Passive[(
library_unit_name)];
Legality Rules
4/3
{
AI05-0243-1}
A
pragma
Shared_Passive is used to specify that a library unit is a shared
passive library unit, namely that the is a library unit to which a Shared_Passive
aspect
of the library unit is True pragma applies.
The following restrictions apply to such a library unit:
4.a/3
Aspect Description
for Shared_Passive: A
given package is used to represent shared memory in a distributed system.
5
[it shall be preelaborable (see
10.2.1);]
5.a
Ramification: It cannot contain library-level
declarations of protected objects with entries, nor of task objects.
Task objects are disallowed because passive partitions don't have any
threads of control of their own, nor any run-time system of their own.
Protected objects with entries are disallowed because an entry queue
contains references to calling tasks, and that would require in effect
a pointer from a passive partition back to a task in some active partition.
6/3
6.a
Reason: Shared passive packages cannot
depend semantically upon remote types packages because the values of
an access type declared in a remote types package refer to the local
heap of the active partition including the remote types package.
6.b/3
7/1
{
8652/0080}
{
AI95-00003-01}
it shall not contain a library-level declaration of an access type that
designates a class-wide type, task type, or protected type with
entry_declarations
;
if the shared passive library unit is generic, it shall not contain a
declaration for such an access type unless the declaration is nested
within a body other than a package_body.
7.a
Reason: These kinds of access types are
disallowed because the object designated by an access value of such a
type could contain an implicit reference back to the active partition
on whose behalf the designated object was created.
8
Notwithstanding
the definition of accessibility given in
3.10.2,
the declaration of a library unit P1 is not accessible from within the
declarative region of a shared passive library unit P2, unless the shared
passive library unit P2 depends semantically on P1.
8.a
Discussion: We considered a more complex
rule, but dropped it. This is the simplest rule that recognizes that
a shared passive package may outlive some other library package, unless
it depends semantically on that package. In a nondistributed program,
all library packages are presumed to have the same lifetime.
8.b
Implementations may define additional pragmas
that force two library packages to be in the same partition, or to have
the same lifetime, which would allow this rule to be relaxed in the presence
of such pragmas.
Static Semantics
9
A shared passive library unit
is preelaborated.
Post-Compilation Rules
10
A shared passive library unit shall be assigned to
at most one partition within a given program.
11
Notwithstanding
the rule given in
10.2, a compilation unit
in a given partition does not
need (in the sense of
10.2)
the shared passive library units on which it depends semantically to
be included in that same partition; they will typically reside in separate
passive partitions.
Wording Changes from Ada 95
11.a/2
{
8652/0080}
{
AI95-00003-01}
Corrigendum: Corrected the wording to allow
access types in blocks in shared passive generic packages. Extensions to Ada 2005
11.b/3
{
AI05-0243-1}
Shared_Passive is now a categorization
aspect, so it can be specified by an aspect_specification
— although the pragma is still preferred by the Standard.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
