CVS difference for ai05s/ai05-0111-3.txt
--- ai05s/ai05-0111-3.txt 2010/10/26 05:39:46 1.3
+++ ai05s/ai05-0111-3.txt 2010/11/12 04:15:49 1.4
@@ -1,4 +1,4 @@
-!standard 4.8(2) 10-10-14 AI05-0111-3/02
+!standard 4.8(2) 10-10-28 AI05-0111-3/03
!standard 4.8(3/2)
!standard 4.8(10.3/2)
!standard 13.11(16/3)
@@ -123,7 +123,7 @@
-- An access type must have a storage pool of a type
-- descended from this type to use subpools.
- type Root_Subpool is tagged limited private;
+ type Root_Subpool is abstract tagged limited private;
-- The subpool object type. Objects of this type are managed by
-- the storage pool; usually only the handles are exposed
-- to clients.
@@ -147,9 +147,9 @@
return access Root_Storage_Pool_with_Subpools'Class;
-- Return access to underlying storage pool of given handle.
- procedure Reset_Pool_of_Subpool(Subpool : Subpool_Handle;
- To : in out Root_Storage_Pool_with_Subpools'Class);
- -- (Re)set the Pool for a newly created subpool or a subpool which
+ procedure Set_Pool_of_Subpool(Subpool : Subpool_Handle;
+ To : in out Root_Storage_Pool_with_Subpools'Class);
+ -- Set the Pool for a newly created subpool or a subpool which
-- be being reused after a call to Deallocate_Subpool (this routine
-- should only be used as part of the implementation of Create_Subpool
-- or similar subpool constructors).
@@ -210,7 +210,7 @@
Root_Storage_Pools_with_Subpools, any subpools belonging to the pool
not previously explicitly finalized are explicitly finalized.
(A subpool *belongs* to the pool which was passed to the call of
-Reset_Pool_of_Subpool for the subpool. The relationship continues until
+Set_Pool_of_Subpool for the subpool. The relationship continues until
the designated object of the subpool handle is finalized.)
Legality Rules
@@ -219,79 +219,21 @@
an access type, the access type is called a *subpool access type*. A subpool
access type shall be a pool-specific access type.
+The accessibility level of the subpool access type shall not be statically
+deeper than that of the storage pool object.
+
Dynamic Semantics
-When converting an access value of a subpool access type to a general access
-type, the accessibility level is that of the innermost program unit
-or declare block enclosing the conversion.
-
- AARM NOTE: In other words, it can only be converted to a local access
- type, or to an access discriminant or access parameter. Converting
- back from the access parameter to a named general access type is
- similarly limited to a local access type.]
-
-[Editor's note: Tucker had this rule here, but I suspect that we have
-to put it into 3.10.2. That would make it more complicated; I've left it
-here for now.
-
-Editor's note for version /2: I'm not sure that we really need this rule.
-I left it for now, but note that it makes it impossible to use anonyomous
-access types to work around the ordering rule. As this is intended to
-be exactly as safe as Unchecked_Deallocation (for which there is no
-special restriction), I don't off-hand know of any need for it.]
-
-The *latest subtype with a non-static constraint* of a subtype S is:
- * the completion of S; if S is the first subtype of an incomplete type;
- * S; if S is some other first subtype;
- * the latest subtype with a non-static constraint of the subtype_mark
- of the subtype_indication defining S if the constraint of the
- subtype_indication is static (see 4.9) Redundant[; including when there
- is no constraint];
- * S; otherwise.
-
-AARM Ramification: S includes anonymous subtypes.
-
-A check is made that the elaboration of the latest subtype with a non-static
-constraint of the designated type of a subpool access type S occurs before the
-elaboration of the storage pool object of S and that the elaboration is executed
-by the same task. Program_Error is raised if this check fails.
-
-[Editor's note: This could be a post-compilation check; I didn't make it
-one as it is closely related to elaboration checks, and those checks are
-regular runtime checks. It might actually be easier to implement as a post-compilation
-check (no runtime description of the elaboration order of packages is needed).
-There is more on this check in the discussion section.]
+When a subpool access type is frozen (see 13.14), a check is made that the
+accessibility level of the subpool access type is not deeper than that of
+the storage pool object. Program_Error is raised if this check fails.
AARM Reason:
- This check ensures that the type and any constraints of the allocated objects
- exist longer than the storage pool object, so that the subpools are finalized
- (which finalizes any remaining allocated objects) before the type of the objects
- ceases to exist. The access type itself will cease to exist before the storage
- pool. The check excludes subtypes with static constraints (or no constraints)
- as these cannot depend on any elaboration; excluding them gives a longer
- window in which the storage pool object may be declared.
-
- AARM Implementation Note:
- This check can be implemented with a minimum of distributed overhead. Both
- the latest subtype with a non-static constraint of the designated subtype
- and the storage pool object have to be within the scope of the access type
- (otherwise, they could not have been given in the declaration). If the
- two declarations are in the same compilation unit (or one is in a subunit of
- the compilation unit containing the other), then the compiler can
- examine the structure of the unit to determine whether or not the check
- fails. (If the subtype and object are in the same declarative part,
- examining the order of declarations will determine the answer; if the subtype
- is more nested than the object, the check fails; otherwise, if the object
- and subtype are in different tasks, the check fails.)
-
- If the two declarations are in different compilation units, it is a bit more
- complex. If the subtype is declared in a procedure, the check fails;
- if the object is declared in a procedure the check succeeds. If both items are
- declared at library level in packages, it is necessary to check the order of
- elaboration of the two packages: the check fails if the package containing the
- object is elaborated before the package containing the subtype.
- End AARM Implementation Note.
-
+ This check (and its static counterpart) ensures that the type of the allocated
+ objects exist at least as long as the storage pool object, so that the subpools
+ are finalized (which finalizes any remaining allocated objects) before the type
+ of the objects cease to exist. The access type itself will cease to exist before
+ the storage pool.
13.11.5 Subpool Reclamation
@@ -347,12 +289,11 @@
The only extra requirement on the programmer of a storage pool that
supports subpools is that the actual subpool object is passed to a call of
-Reset_Pool_for_Subpool before it is used. (If this is not done, any
+Set_Pool_for_Subpool before it is used. (If this is not done, any
allocator on that subpool handle will raise Program_Error.)
The implementation may use this routine to initialize the data structures
it uses to handle finalization and task dependence. Note that the routine
-is called "Reset_xxx" rather than "Set_xxx"; this means that it can be
-used to reuse a subpool object after the object is explicitly finalized
+can be used to reuse a subpool object after the object is explicitly finalized
and the associated storage freed. This allows the use of statically allocated
subpool objects (as in the example below).
@@ -395,31 +336,20 @@
Since the objects allocated into a subpool may be finalized before or after
the associated access type(s), we have to take care that the objects are
-not finalized after their (sub)type is finalized. Note that the important
+not finalized after their (sub)type ceases to exist. Note that the important
(sub)type is the designated type (that is the type of the allocated objects),
-not the access type. Thus we adopt a straightforward rule that the designated
-subtype has to be elaborated before the storage pool object.
-
-The rule is designed to ignore subtypes with static (or no) constraints, in
-order to give the maximum "window" in which to declare the storage pool object.
-A subtype with a static constraint cannot depend on any runtime elaborated
-entities, so it is safe to ignore for the purposes of this check.
-
-In the interest of simplicity, we require both the designated subtype and
-the storage pool object to be elaborated by the same task. In almost all uses,
-the types and objects will all be declared at library-level, so this is not
-going to have a significant effect on usability, and it simplifies the
-implementation of the check. (This restriction also makes it possible to
-implement this check as a post-compilation check.)
+not the access type. Even so, the easiest way to make this check is to
+require that the access type is not deeper than the pool.
Alternatives
-This check does make structuring code that uses subpools harder. We considered
-doing without the check by adding an additional runtime rule that the finalization
-of a collection for an access type also finalizes any objects allocated from
-a subpool for that access type. (Along with a similar rule for task dependence.)
+This accessibility check does put restrictions on the location of access types that
+use subpools. We considered doing without the check by adding an additional runtime
+rule that the finalization of a collection for an access type also finalizes any
+objects allocated from a subpool for that access type. (Along with a similar rule
+for task dependence.)
-This eliminates any problems with ordering and would allow subpools to be used
+This eliminates the static restrictions and would allow subpools to be used
on access types with nested designated types and the like.
However, the implementation would be complex. An obvious implementation would
@@ -466,6 +396,8 @@
-- from a subpool other than the one at the top of the stack. This is also
-- the default pool.
+ subtype Subpool_Handle is System.Subpools.Subpool_Handle;
+
type Mark_Release_Pool_Type (Pool_Size : Storage_Elements.Storage_Count) is new
System.Subpools.Root_Storage_Pool_with_Subpools with private;
@@ -534,8 +466,8 @@
-- Initialize the first default subpool.
begin
Pool.Markers(1).Start := 1;
- System.Subpools.Reset_Pool_for_Subpool (Pool.Markers(1)'Unchecked_Access,
- Pool'Unchecked_Access);
+ System.Subpools.Set_Pool_for_Subpool (Pool.Markers(1)'Unchecked_Access,
+ Pool'Unchecked_Access);
end Initialize;
function Create_Subpool (Pool : aliased in out Mark_Release_Pool_Type;
@@ -548,8 +480,8 @@
end if;
Pool.Current_Pool := Pool.Current_Pool + 1; -- More to the next subpool
Pool.Markers(Pool.Current_Pool).Start := Pool.Next_Allocation;
- System.Subpools.Reset_Pool_for_Subpool (Pool.Markers(Pool.Current_Pool)'Unchecked_Access,
- Pool'Unchecked_Access);
+ System.Subpools.Set_Pool_for_Subpool (Pool.Markers(Pool.Current_Pool)'Unchecked_Access,
+ Pool'Unchecked_Access);
return Pool(Pool.Current_Pool).Markers'Unchecked_Access;
end Create_Subpool;
@@ -561,12 +493,12 @@
raise Program_Error; -- Only the last marked subpool can be released.
end if;
if Pool.Current_Pool /= 1 then
- Pool.Current_Pool := Pool.Current_Pool - 1; -- More to the previous subpool
Pool.Next_Allocation := Pool.Markers(Pool.Current_Pool);
+ Pool.Current_Pool := Pool.Current_Pool - 1; -- More to the previous subpool
else -- Reinitialize the default subpool:
Pool.Next_Allocation := 1;
- System.Subpools.Reset_Pool_for_Subpool (Pool.Markers(1)'Unchecked_Access,
- Pool'Unchecked_Access);
+ System.Subpools.Set_Pool_for_Subpool (Pool.Markers(1)'Unchecked_Access,
+ Pool'Unchecked_Access);
end if;
end Deallocate_Subpool;
Questions? Ask the ACAA Technical Agent