[Home] [Prev] [Next] [Index]

E.2 Categorization of Library Units

E.2 Categorization of Library Units

1
[Library units can be categorized according to the role they play in a distributed program.  Certain restrictions are associated with each category to ensure that the semantics of a distributed program remain close to the semantics for a nondistributed program.]

2
A categorization pragma is a library unit pragma (see 10.1.5) that restricts the declarations, child units, or semantic dependences of the library unit to which it applies. A categorized library unit is a library unit to which a categorization pragma applies.

3
The pragmas Shared_Passive, Remote_Types, and Remote_Call_Interface are categorization pragmas. In addition, for the purposes of this Annex, the pragma Pure (see 10.2.1) is considered a categorization pragma.

4
A library package or generic library package is called a shared passive library unit if a Shared_Passive pragma applies to it. A library package or generic library package is called a remote types library unit if a Remote_Types pragma applies to it. A library package or generic library package is called a remote call interface if a Remote_Call_Interface pragma applies to it. A normal library unit is one to which no categorization pragma applies.

5
[The various categories of library units and the associated restrictions are described in this clause and its subclauses. The categories are related hierarchically in that the library units of one category can depend semantically only on library units of that category or an earlier one, except that the body of a remote types or remote call interface library unit is unrestricted.

6
The overall hierarchy (including declared pure) is as follows:

7
Declared Pure Can depend only on other declared pure library units;

8
Shared Passive Can depend only on other shared passive or declared pure library units;

9
Remote Types The declaration of the library unit can depend only on other remote types library units, or one of the above; the body of the library unit is unrestricted;

10
Remote Call Interface The declaration of the library unit can depend only on other remote call interfaces, or one of the above; the body of the library unit is unrestricted;

11
Normal Unrestricted.

12
Declared pure and shared passive library units are preelaborated. The declaration of a remote types or remote call interface library unit is required to be preelaborable.]

Implementation Requirements

13
For a given library-level type declared in a preelaborated library unit or in the declaration of a remote types or remote call interface library unit, the implementation shall choose the same representation for the type upon each elaboration of the type's declaration for different partitions of the same program.

Implementation Permissions

14
Implementations are allowed to define other categorization pragmas.

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
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 ·
[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 ·
it shall depend semantically only upon declared pure or shared passive library units;

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 ·
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.

E.2.2 Remote Types Library Units

1
[A remote types library unit supports the definition of types intended for use in communication between active partitions.]

Language Design Principles

1.a
The restrictions governing a remote types package are similar to those for a declared pure package. However, the restrictions are relaxed deliberately to allow such a package to contain declarations that violate the stateless property of pure packages, though it is presumed that any state-dependent properties are essentially invisible outside the package.

Syntax

2
The form of a pragma Remote_Types is as follows:

3
pragma Remote_Types[(library_unit_name)];

Legality Rules

4
A remote types library unit is a library unit to which the pragma Remote_Types applies. The following restrictions apply to the declaration of such a library unit:

5 ·
[it shall be preelaborable;]

6 ·
it shall depend semantically only on declared pure, shared passive, or other remote types library units;

7 ·
it shall not contain the declaration of any variable within the visible part of the library unit;

7.a
Reason: This is essentially a "methodological" restriction. A separate copy of a remote types package is included in each partition that references it, just like a normal package. Nevertheless, a remote types package is thought of as an "essentially pure" package for defining types to be used for interpartition communication, and it could be misleading to declare visible objects when no remote data access is actually being provided.

8 ·
if the full view of a type declared in the visible part of the library unit has a part that is of a non-remote access type, then that access type, or the type of some part that includes the access type subcomponent, shall have user-specified Read and Write attributes.

8.a
Reason: This is to prevent the use of the predefined Read and Write attributes of an access type as part of the Read and Write attributes of a visible type.

9
An access type declared in the visible part of a remote types or remote call interface library unit is called a remote access type. Such a type shall be either an access-to-subprogram type or a general access type that designates a class-wide limited private type.

10
The following restrictions apply to the use of a remote access-to-subprogram type:

11 ·
A value of a remote access-to-subprogram type shall be converted only to another (subtype-conformant) remote access-to-subprogram type;

12 ·
The prefix of an Access attribute_reference that yields a value of a remote access-to-subprogram type shall statically denote a (subtype-conformant) remote subprogram.

13
The following restrictions apply to the use of a remote access-to-class-wide type:

14 ·
The primitive subprograms of the corresponding specific limited private type shall only have access parameters if they are controlling formal parameters; the types of all the non-controlling formal parameters shall have Read and Write attributes.

15 ·
A value of a remote access-to-class-wide type shall be explicitly converted only to another remote access-to-class-wide type;

16 ·
A value of a remote access-to-class-wide type shall be dereferenced (or implicitly converted to an anonymous access type) only as part of a dispatching call where the value designates a controlling operand of the call (see E.4, "Remote Subprogram Calls");

17 ·
The Storage_Pool and Storage_Size attributes are not defined for remote access-to-class-wide types; the expected type for an allocator shall not be a remote access-to-class-wide type; a remote access-to-class-wide type shall not be an actual parameter for a generic formal access type;

17.a
Reason: All three of these restrictions are because there is no storage pool associated with a remote access-to-class-wide type.

NOTES

18 5
A remote types library unit need not be pure, and the types it defines may include levels of indirection implemented by using access types. User-specified Read and Write attributes (see 13.13.2) provide for sending values of such a type between active partitions, with Write marshalling the representation, and Read unmarshalling any levels of indirection.

E.2.3 Remote Call Interface Library Units

1
[A remote call interface library unit can be used as an interface for remote procedure calls (RPCs) (or remote function calls) between active partitions.]

Language Design Principles

1.a
The restrictions governing a remote call interface library unit are intended to ensure that the values of the actual parameters in a remote call can be meaningfully sent between two active partitions.

Syntax

2
The form of a pragma Remote_Call_Interface is as follows:

3
pragma Remote_Call_Interface[(library_unit_name)];

4
The form of a pragma All_Calls_Remote is as follows:

5
pragma All_Calls_Remote[(library_unit_name)];

6
A pragma All_Calls_Remote is a library unit pragma.

Legality Rules

7
A remote call interface (RCI) is a library unit to which the pragma Remote_Call_Interface applies. A subprogram declared in the visible part of such a library unit is called a remote subprogram.

8
The declaration of an RCI library unit shall be preelaborable (see 10.2.1), and shall depend semantically only upon declared pure, shared passive, remote types, or other remote call interface library units.

9
In addition, the following restrictions apply to the visible part of an RCI library unit:

10 ·
it shall not contain the declaration of a variable;

10.a
Reason: Remote call interface packages do not provide remote data access.  A shared passive package has to be used for that.

11 ·
it shall not contain the declaration of a limited type;

11.a
Reason: We disallow the declaration of task and protected types, since calling an entry or a protected subprogram implicitly passes an object of a limited type (the target task or protected object). We disallow other limited types since we require that such types have user-defined Read and Write attributes, but we certainly don't want the Read and Write attributes themselves to involve remote calls (thereby defeating their purpose of marshalling the value for remote calls).

12 ·
it shall not contain a nested generic_declaration;

12.a
Reason: This is disallowed because the body of the nested generic would presumably have access to data inside the body of the RCI package, and if instantiated in a different partition, remote data access might result, which is not supported.

13 ·
it shall not contain the declaration of a subprogram to which a pragma Inline applies;

14 ·
it shall not contain a subprogram (or access-to-subprogram) declaration whose profile has an access parameter, or a formal parameter of a limited type unless that limited type has user-specified Read and Write attributes;

15 ·
any public child of the library unit shall be a remote call interface library unit.

15.a
Reason: No restrictions apply to the private part of an RCI package, and since a public child can "see" the private part of its parent, such a child must itself have a Remote_Call_Interface pragma, and be assigned to the same partition (see below).

15.b
Discussion:  We considered making the public child of an RCI package implicitly RCI, but it seemed better to require an explicit pragma to avoid any confusion.

15.c
Note that there is no need for a private child to be an RCI package, since it can only be seen from the body of its parent or its siblings, all of which are required to be in the same active partition.

16
If a pragma All_Calls_Remote applies to a library unit, the library unit shall be a remote call interface.

Post-Compilation Rules

17
A remote call interface library unit shall be assigned to at most one partition of a given program. A remote call interface library unit whose parent is also an RCI library unit shall be assigned only to the same partition as its parent.

17.a
Implementation Note: The declaration of an RCI package, with a calling-stub body, is automatically included in all active partitions with compilation units that depend on it. However the whole RCI library unit, including its (non-stub) body, will only be in one of the active partitions.

18
Notwithstanding the rule given in 10.2, a compilation unit in a given partition that semantically depends on the declaration of an RCI library unit, needs (in the sense of 10.2) only the declaration of the RCI library unit, not the body, to be included in that same partition. [Therefore, the body of an RCI library unit is included only in the partition to which the RCI library unit is explicitly assigned.]

Implementation Requirements

19
If a pragma All_Calls_Remote applies to a given RCI library package, then the implementation shall route any call to a subprogram of the RCI package from outside the declarative region of the package through the Partition Communication Subsystem (PCS); see E.5. Calls to such subprograms from within the declarative region of the package are defined to be local and shall not go through the PCS.

19.a
Discussion:  Without this pragma, it is presumed that most implementations will make direct calls if the call originates in the same partition as that of the RCI package.  With this pragma, all calls from outside the subsystem rooted at the RCI package are treated like calls from outside the partition, ensuring that the PCS is involved in all such calls (for debugging, redundancy, etc.).

19.b
Reason: There is no point to force local calls (or calls from children) to go through the PCS, since on the target system, these calls are always local, and all the units are in the same active partition.

Implementation Permissions

20
An implementation need not support the Remote_Call_Interface pragma nor the All_Calls_Remote pragma. [Explicit message-based communication between active partitions can be supported as an alternative to RPC.]

20.a
Ramification: Of course, it is pointless to support the All_Calls_Remote pragma if the Remote_Call_Interface pragma (or some approximate equivalent) is not supported.



[Home] [Prev] [Next] [Index]

documentation@rational.com
Copyright © 1993-1998, Rational Software Corporation.   All rights reserved.