Ada Conformity Assessment Authority      Home Conformity Assessment   Test Suite ARGAda Standard
Annotated Ada Reference Manual (Ada 2022)Legal Information
Contents   Index   References   Search   Previous   Next 

E.2.1 Shared Passive Library Units

[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

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. 


{AI12-0417-1} The form of a pragma Shared_Passive is as follows: 
{AI12-0417-1}   pragma Shared_Passive[(library_unit_name)];
Paragraphs 2 and 3 were moved to Annex J, “Obsolescent Features”. 

Legality Rules

{AI05-0243-1} {AI12-0417-1} When the library unit aspect (see 13.1.1) A pragma Shared_Passive of is used to specify that a library unit is True, the library unit is a a shared passive library unit, namely that the Shared_Passive aspect of the library unit is True. The following restrictions apply to such a library unit:
Aspect Description for Shared_Passive: A given package is used to represent shared memory in a distributed system.
[it shall be preelaborable (see 10.2.1);]
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.
{AI05-0243-1} it shall depend semantically only upon declared pure or shared passive library_items;
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. 
Ramification: {AI05-0243-1} We say library_item here, so that limited views are allowed; those are not library units, but they are library_item.
{8652/0080} {AI95-00003-01} {AI12-0038-1} {AI12-0320-1} it shall not contain a library-level declaration: of an access type that designates a class-wide type, nor a type with a part that is of a task type, or protected type with entry_declarations;.
{AI12-0320-1} of an access type that designates a class-wide type; 
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. 
{AI12-0320-1} of a type with a part that is of a task type;
{AI12-0320-1} of a type with a part that is of a protected type with entry_declarations; or
{AI12-0038-1} {AI12-0320-1} it shall not contain a library-level declaration that contains a name that denotes a type declared within a declared-pure package, if that type has a part that is of an access type; for the purposes of this rule, the parts considered include those of the full views of any private types or private extensions.
Reason: This rule breaks privacy by looking into the full views of private types. Avoiding privacy breakage here would have required disallowing the use in a shared passive package of any private type declared in a declared-pure package, which would have been severely incompatible. 
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. 
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.
{AI12-0417-1} Implementations may define additional aspects or 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 aspects or pragmas.

Static Semantics

A shared passive library unit is preelaborated.

Post-Compilation Rules

A shared passive library unit shall be assigned to at most one partition within a given program.
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.
To be honest: {AI12-0359-1} This rule is necessary so that the shared data of a shared passive partition is not duplicated in each partition. It does not imply a particular implementation; in particular, code can be replicated in each active partition. 
Implementation Note: {AI12-0359-1} One possible implementation for a shared passive partition is as a shared library that is mapped into the address space of of each active partition. In such case, both the code and the data of the passive partition would be mapped into the active partitions and directly called/accessed from each active partition. For instance, on Microsoft Windows a DLL has the correct semantics.
Alternatively, the shared data can be represented as a file or persistent memory, with the shared code being replicated in each active partition. Code replication is an as-if optimization; it should be impossible to tell where the code lives since no elaboration is necessary. 

Wording Changes from Ada 95

{8652/0080} {AI95-00003-01} Corrigendum: Corrected the wording to allow access types in blocks in shared passive generic packages. 

Extensions to Ada 2005

{AI05-0243-1} {AI12-0417-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 Reference Manual.

Incompatibilities With Ada 2012

{AI12-0038-1} Corrigendum: Uses of access types declared in declared-pure units are not allowed in library-level shared passive packages. These were allowed by Ada 2005 and Ada 2012, but it is unlikely that they work properly, as active partitions could disappear before the shared-passive partition. As such, the new errors are more likely to catch bugs than to cause them. 

Wording Changes from Ada 2012

{AI12-0417-1} The pragma Shared_Passive is now obsolescent.

Contents   Index   References   Search   Previous   Next 
Ada-Europe Ada 2005 and 2012 Editions sponsored in part by Ada-Europe