CVS difference for ai05s/ai05-0009-1.txt
--- ai05s/ai05-0009-1.txt 2006/03/23 03:30:58 1.1
+++ ai05s/ai05-0009-1.txt 2006/11/14 00:06:28 1.2
@@ -1,4 +1,4 @@
-!standard 9.10(1) 06-03-21 AI05-0009-1/01
+!standard 9.10(1) 06-11-06 AI05-0009-1/02
!class binding interpretation 06-03-21
!status work item 06-03-21
!status received 06-02-20
@@ -9,8 +9,12 @@
!summary
-(See recommendation.)
+A new pragma Independent_Components allows a user to specify that the components
+of an object or type should be independently addressable.
+Objects or types that have a convention specified by an interfacing pragma may not
+be independently addressable.
+
!question
9.10(1) says that two nonoverlapping objects are independently addressable unless one or
@@ -25,15 +29,76 @@
Add pragma Independent_Components (type_local_NAME); which specifies that
independence must be guaranteed for the given type. The pragma must be rejected
-if independence cannot be guaranteed.
+if independence cannot be guaranteed. Add implementation advice for independently
+addressable objects.
-[We either need something for stand-alone objects, or we are requiring them to always
-be independent (that should be the default in that case).]
+Modify 13.1 (21.1/2) include independently addressable components for confirming
+representations.
!wording
+
+Replace 9.10(1) with:
+
+If two different objects, including nonoverlapping parts of the same
+object, are independently addressable, they can be manipulated
+concurrently by two different tasks without synchronization.
+Normally, any two nonoverlapping objects are independently
+addressable. However, if packing, record layout, Component_Size, or
+convention is specified for a given composite object, then it is
+implementation defined whether or not two nonoverlapping parts of
+that composite object are independently addressable. Pragma
+Independent_Components may be used to specify that components are
+independently addressable.
+
+Syntax
+
+The form of a pragma Independent_Components is as follows:
+
+pragma Independent_Components (
+ [Entity => ] local_name
+ {,[Component =>] *component*_local_name});
+
+Name Resolution Rules
+
+The local_name in a Independent_Components pragma shall resolve to
+denote a composite type, an anonymous array object or an object to
+which an interface pragma applies.
+
+Legality Rules
+
+It is illegal to apply a Independent_Components pragma to an object
+or type if the implementation cannot support independently
+addressable components for the object or type.
+
+Static Semantics
+
+Pragma Independent_Components specifies that the named components
+(or all components if none are named) are independently addressable.
+
+Pragma Independent_Components is a representation pragma.
+
+Add after 9.10(15):
+
+Implementation Advice
+
+The recommended level of support for independently addressable
+objects is:
-(TBD.)
+* The implementation should use an indivisible operation to update
+ the elementary independently addressable parts of an object when
+ the target hardware provides such an operation.
+* The implementation should avoid update of other objects or other
+ subcomponents of the same object when updating an independently
+ addressable part of an object. However, sequential updates of
+ subcomponents of an object may be combined into a single operation.
+
+Replace 13.1(21.1/2) with:
+
+A confirming representation item should be supported, where
+components (if any) are independently addressable.
+
+
!discussion
The intent of AI95-291-2 is that confirming representation clauses can always be given
@@ -42,6 +107,26 @@
Convention can affect independence; if the foreign representation is one that cannot
guarantee independence, we don't want to have to reject the representation clause.
+Convention was added to the list of representation items impacting
+addressability rather than creating an explicit statement identifying
+convention as dependently addressable to avoid creating a special
+case (not as recommended in the Porto minutes). Addition of
+convention requires the inclusion of objects as parameters to the
+pragmas.
+
+9.10(16)
+
+The provision to allow multiple writes to the same object provides
+for those target architectures that do not support a single write
+instruction for large elementary objects, such as IEEE 754 Long
+Floats.
+
+9.10 (17)
+
+The implementation advice places a constraint on the use of a
+"Block Move" operation to copy data: an unaligned store operation
+must avoid the partial update of a subcomponent.
+
!ACATS test
Since it is implementation-defined if any two objects are independently addressable,
@@ -1624,6 +1709,265 @@
that a set of conforming rep clauses must include the independence
pragma (of course you could leave it out if you were not interested
in separate task access).
+
+****************************************************************
+
+From: Bibb Latting
+Sent: Monday, November 6, 2006 5:21 PM
+
+While working on this AI, I had the following questions regarding
+both the text of the AI and what should or shouldn't be included:
+
+9.10 (1)
+
+How about removing implementation defined from this paragraph.
+Something along the lines of:
+
+"However, representation items such as packing and record layout may
+prevent a subcomponent of an object from being independently
+addressable."
+
+
+9.10 (16 and 17)
+
+Should the implementation advice attempt to include update of any
+implementation data such as array doping or other hidden data?
+
+Should some documentation recommendation be added that identifies
+those elementary values, if any, that are not suitable for use with
+multiple tasks?
+
+
+Dependently Addressable Objects
+
+Should an implementation permission be given to allow generation of
+an instruction sequence which might break inter-task synchronization
+when an object is not independently addressable?
+
+
+High Integrity
+
+Are there any appropriate restrictions applicable for "pragma
+Independent_Components". Specifically, should D.7, Tasking
+Restrictions; D.13.1, The "Ravenscar" profile, and H.4 High Integrity
+Restrictions contain a restriction to prevent the use of
+"Independent_Components"?
+
+
+Privacy
+
+Using independent addressing as the default synchronization method
+causes a dreadful headache when considering privacy. Might the
+introduction of a "Pragma Independent" as some sort of recursive
+application of pragma Independent_Components partially mitigate this
+problem?
+
+
+Initialized Discriminates
+
+The behavior of assignment to initialized discriminates is
+problematic here; should initialized discriminates be explicitly
+excluded from those objects which are independently addressable?
+
+Should an initialized discriminate be cause to reject a pragma
+Independent_Components?
+
+
+Independent Addressability
+
+Should pragma Independent_Components cause rejection of elementary
+components which are independently addressable, but can not be
+updated using an indivisible operation?
+
+Should a pragma be provided to assure thread-safe elementary object
+representation and instruction selection (as opposed to the
+flexibility associated with independent addressability)?
+
+
+Memory Segment Allocation
+
+What relevance, if any, does segment allocation have with regards to
+inter-task data sharing (a segment can be "local" or "shared" on
+some architectures), particularly on multi-processor systems? Is
+there a default that needs to be addressed?
+
+
+Notes
+
+13.1 (21.1) was selected for implementation advice for confirming
+representations to avoid implementation advice for each item
+(e.g. 13.1 (21.1) recommends a confirming representation for pragma
+pack, which is considered to be non-confirming). 9.10 was discarded
+as an appropriate location because of the unnecessary forward
+reference to a confirming representation.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, November 7, 2006 6:59 PM
+
+> While working on this AI, I had the following questions regarding
+> both the text of the AI and what should or shouldn't be included:
+>
+> 9.10 (1)
+>
+> How about removing implementation defined from this paragraph.
+> Something along the lines of:
+>
+> "However, representation items such as packing and record layout may
+> prevent a subcomponent of an object from being independently
+> addressable."
+
+Why? "implementation-defined" means it is supposed to be documented somehow.
+That means users have a way to find out what happens. Granted, using the new
+pragma it probably better than depending on implementation-defined behavior.
+But I think we want to make as little change here as possible (we don't want
+to break existing programs).
+
+> 9.10 (16 and 17)
+>
+> Should the implementation advice attempt to include update of any
+> implementation data such as array doping or other hidden data?
+
+I don't know how you could do that. Objects are independent unless the
+language says that they don't have to be, so any hidden stuff also has to be
+independent. And we almost never talk about implementation artifacts: the
+implementation is supposed to handle those correctly. If the objects aren't
+independent, then any dope wouldn't need to be, either.
+
+> Should some documentation recommendation be added that identifies
+> those elementary values, if any, that are not suitable for use with
+> multiple tasks?
+
+Robert Dewar will say that documentation requirements are junk. Besides,
+your question doesn't make sense. Independent addressability merely says
+that two tasks can access *different* objects (inc. components) without
+interference. That surely must be possible for all types in the absence of
+representation items. (Just put one Boolean per byte, for instance.) We
+expect compilers to get this right.
+
+> Dependently Addressable Objects
+>
+> Should an implementation permission be given to allow generation of
+> an instruction sequence which might break inter-task synchronization
+> when an object is not independently addressable?
+
+We always have to talk in terms of two objects when we're talking about
+independently addressable. It seems like you might be confusing independent
+addressibility with Atomic. The language seems clear that if two objects are
+not independently addressible, then the tasks might need some explicit
+synchronization to access them. I don't see that anything about this has
+anything to do with "instruction sequences" (that's Atomic). If I'm wrong,
+perhaps an example of the problem would help.
+
+> High Integrity
+>
+> Are there any appropriate restrictions applicable for "pragma
+> Independent_Components". Specifically, should D.7, Tasking
+> Restrictions; D.13.1, The "Ravenscar" profile, and H.4 High Integrity
+> Restrictions contain a restriction to prevent the use of
+> "Independent_Components"?
+
+Huh again? Why would you *not* want Independent_Components, as it prevents
+dependencies not shown in the source code. It might be nice to have a
+restriction to flag things that are *not* independently addressable -- but
+that surely was an issue in Ada 95, and it wasn't considered important
+enough to bother with.
+
+> Privacy
+>
+> Using independent addressing as the default synchronization method
+> causes a dreadful headache when considering privacy. Might the
+> introduction of a "Pragma Independent" as some sort of recursive
+> application of pragma Independent_Components partially mitigate this
+> problem?
+
+Huh again? Independent addressibility is *not* a synchronization method!!
+That's Atomic (see C.6). It merely says that things will work as expected,
+when two tasks access *different* objects. When an objects/components are
+not independently addressable, then there can be interference between them
+even if they are semantically separate.
+
+For instance, if we have:
+ type Rec is record
+ B1, B2 : Boolean;
+ end record;
+ pragma Independent_Components (Rec);
+ Obj : Rec;
+
+then if task T1 accesses Obj.B1, and task T2 accesses Obj.B2, no
+synchronization is needed. OTOH, if we replaced Independent_Components by
+Pack, then there is no guarantee that T1 and T2 can access the two
+components of Obj without trouble. (This is more interesting with arrays,
+but I'm giving the example as a record because it is easier to write and
+understand.)
+
+> Initialized Discriminates
+>
+> The behavior of assignment to initialized discriminates is
+> problematic here; should initialized discriminates be explicitly
+> excluded from those objects which are independently addressable?
+>
+> Should an initialized discriminate be cause to reject a pragma
+> Independent_Components?
+
+I don't see any reason that initialized discriminants have any bearing on
+this at all. Please explain with an example.
+
+
+> Independent Addressability
+>
+> Should pragma Independent_Components cause rejection of elementary
+> components which are independently addressable, but can not be
+> updated using an indivisible operation?
+
+Indivisible operations are those for Atomic. You're thinking of
+Atomic_Components again. The only reason I can think of for rejecting
+Independent_Components is if another rep. clause requires a mask-and-store
+implementation:
+ type Arr is (1..8) of Boolean;
+ for Arr'Component_Size use 1;
+ pragma Independent_Components (Arr); -- Reject this.
+
+But if the components are large and require multiple instructions, that's
+not a problem so long as the memory cells in question are separate from any
+other objects cells.
+
+> Should a pragma be provided to assure thread-safe elementary object
+> representation and instruction selection (as opposed to the
+> flexibility associated with independent addressability)?
+
+That sounds like pragma Atomic and Atomic_Components. Or did you have
+something else in mind?
+
+> Memory Segment Allocation
+>
+> What relevance, if any, does segment allocation have with regards to
+> inter-task data sharing (a segment can be "local" or "shared" on
+> some architectures), particularly on multi-processor systems? Is
+> there a default that needs to be addressed?
+
+That level of detail is usually left up to the implementer. Atomic is an
+exception, but we're not talking about that here.
+
+> Notes
+>
+> 13.1 (21.1) was selected for implementation advice for confirming
+> representations to avoid implementation advice for each item
+> (e.g. 13.1 (21.1) recommends a confirming representation for pragma
+> pack, which is considered to be non-confirming). 9.10 was discarded
+> as an appropriate location because of the unnecessary forward
+> reference to a confirming representation.
+
+I'm not sure what this means. There shouldn't need to be any new advice
+about confirming representations. The bug in 9.10 was that confirming rep.
+clauses had a semantic effect, we don't want that ever to be true. For all
+representation items, a confirming clause should be supported (if such a
+thing can be written -- which isn't necessarily possible, because we don't
+have a pragma Unpack to specify the absence of pragma Pack, for one
+example). There is no exception to this rule! We're surely not going to
+distribute some goofy rules about independent addressibility all over the
+standard.
****************************************************************
Questions? Ask the ACAA Technical Agent