Contents   Index   Previous   Next

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
{categorization pragma (Shared_Passive) [partial]} {pragma, categorization (Shared_Passive) [partial]} The form of a pragma Shared_Passive is as follows:
3
  pragma Shared_Passive[(library_unit_name)];

Legality Rules

4
   {shared passive library unit} A shared passive library unit is a library unit to which a Shared_Passive pragma applies. The following restrictions apply to such a library unit:
5
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
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.
7/1
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
   {accessibility (from shared passive library units) [partial]} {notwithstanding} 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
   {preelaborated [partial]} 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
    {compilation units needed (shared passive library unit) [partial]} {needed (shared passive library unit) [partial]} {notwithstanding} 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.

Contents   Index   Previous   Next   Legal