CVS difference for ai12s/ai12-0196-1.txt

Differences between 1.7 and version 1.8
Log of other versions for file ai12s/ai12-0196-1.txt

--- ai12s/ai12-0196-1.txt	2016/11/24 02:41:08	1.7
+++ ai12s/ai12-0196-1.txt	2016/12/28 04:14:29	1.8
@@ -1,4 +1,4 @@
-!standard A.18(2/2)                                 16-11-11   AI12-0196-1/06
+!standard A.18(2/2)                                 16-12-27   AI12-0196-1/07
 !standard A.18.2(125/2)
 !standard A.18.2(133/3)
 !standard A.18.2(135/3)
@@ -26,8 +26,8 @@
 and data structures can be improved. The Ada standard containers are such data
 structures that could be involved in lengthy processing and could be candidates
 for parallelism. Unfortunately, Ada currently says that for concurrent calls,
-the language-defined subprograms are only reentrant if the parameters of the
-call are nonoverlapping.
+the language-defined subprograms are only required to work if the parameters
+of the call are nonoverlapping.
 Most container calls involve a controlling parameter of the container type,
 yet the call on the container may only be affecting a subset of the elements in the
 container, and may not affect state that is global to all of the elements being
@@ -39,10 +39,10 @@
 
 !recommendation
 
-We propose to allow certain operations that manipulate or examine cursors
-(ie. Next, Previous, and Element) to be reentrant if the calls only accept
-a Cursor as a parameter. This is achieved by specifying that cursors only
-overlap with the element they designate. For Vector
+We propose to require certain operations that manipulate or examine cursors
+(ie. Next, Previous, and Element) to work for concurrent calls if the calls
+only accept a Cursor as a parameter. This is achieved by specifying that
+cursors only overlap with the element they designate. For Vector
 containers, we also specify that To_Cursor is Reentrant.
 
 !wording
@@ -54,9 +54,10 @@
 
 Modify AARM A.18(2.a/2)
    Reason: The last sentence is intended to clarify that operations
-   that just use a cursor are {reentrant if the cursor objects designate
-   different elements of the container}[on the same footing as operations that
-   use a container] in terms of the reentrancy rules of Annex A.
+   that just use a cursor {do not interfere if the cursor objects
+   designate different elements of the container}[are on the same footing as
+   operations that use a container] in terms of the
+   {concurrent call}[reentrancy] rules of Annex A.
 
    {Ramification: A cursor is not considered to overlap with other elements of
    the associated container, thus parallel operations involving a set of cursors
@@ -65,6 +66,8 @@
 
 Modify AARM A.18(5.o/2):
 
+   Library packages must {allow concurrent calls}[be reentrant] -- multiple
+   tasks can use the packages as long as they operate on separate containers.
    Thus, it is only necessary for a user to protect a container if a single
    container needs to be used by multiple tasks {and concurrent calls to
    operations of the container have overlapping parameters.}.
@@ -76,7 +79,7 @@
    object Redundant[(including itself)].
 
    AARM Reason: Without the preceding rule, concurrent calls to To_Cursor
-   on the same container would interfere by the reentrancy rules in Annex A,
+   on the same container would interfere by the concurrent call rules in Annex A,
    since the container object of the concurrent calls would overlap with itself.
    We want these to not interfere, for example to allow the Vector elements to
    be split into separate "chunks" for parallel processing.
@@ -136,8 +139,8 @@
 across different compiler implementations.
 
 The first obstacle is that the standard says that a language-defined
-subprogram call is only reentrant if all the parameters of the call
-are nonoverlapping with respect to other active calls.
+subprogram call is required to work with concurrent calls only if all the
+parameters of the call are nonoverlapping with respect to other active calls.
 
 The standard also says that a cursor for a container is to be treated as
 though it overlaps with the container object.
@@ -158,8 +161,8 @@
 obtain the initial cursor for each chunk of the vector. The To_Cursor
 subprogram however has a parameter that is the container associated with the
 cursor to be generated, and thus still is considered to be an overlapping call
-that is not reentrant if concurrent calls are applied to the same container
-object. We solve that by simply declaring otherwise.
+if concurrent calls are applied to the same container object. We solve that by
+simply declaring otherwise.
 
 Thus, To_Cursor can safely be called concurrently since its container
 parameter is said above to not overlap with any object including itself.
@@ -173,7 +176,7 @@
 the Replace_Element subprograms to be called concurrently. The Replace_Element
 subprograms have the same issue as To_Cursor in that they have a parameter
 that is the container containing the element that is to be replaced, and
-would ordinarily be considered to not be reentrant if concurrent calls are
+would ordinarily not be required to work if concurrent calls are
 applied to the same container object, since the container parameter would be
 overlapping. We address this with similar wording that was used for To_Cursor
 to declare that the container parameter does not overlap with anything.
@@ -1085,5 +1088,153 @@
 > with the tampering checks.
 
 Hopefully, I didn't lose anything important. Sorry.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Friday, December 23, 2016  4:51 PM
+
+> Letter Ballot to Approve AI12-0200-1/05:
+...
+> _X__ Reject AI
+> 
+> comments
+> ___This will cause rework for AI 196, as it depends quite heavily on the
+term "reentrant" as it was defined in this paragraph.
+I think reentrant term will still be needed, at least by AI 196. If AI 196
+can be resolved without defining the term Reentrant, then I approve, othewise,
+I think we need to at least reintroduce the term to apply to the new
+definition, so that it can simplify wording elsewhere in the RM.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Friday, December 23, 2016  9:16 PM
+
+> I think reentrant term will still be needed, at least by AI 196. If AI 
+> 196 can be resolved without defining the term Reentrant, then I 
+> approve, othewise, I think we need to at least reintroduce the term to 
+> apply to the new definition, so that it can simplify wording elsewhere 
+> in the RM.
+
+Well, the old text did not exactly define the term either ("shall be reentrant
+in the sense that << very special and even incompletely described case >>...")
+and, even if you let that count as a definition, it is counter to the usual
+definition of the term.
+
+So, if a term needs to be invented, fine, but please not "reentrant" and please
+no "in the sense that". "non-interfering" perhaps, or "race free".
+
+E.g.
+
+Two concurrent calls on any two (possibly the same) language-defined subprograms
+are said to be race free if they perform as specified, as long as all pairs of
+objects (one from each call) that are either denoted by parameters that could
+be passed by reference, or are designated by parameters of an access type, are
+nonoverlapping.
+
+The implementation shall ensure that all concurrent calls on all
+language-defined subprograms are race free.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Friday, December 23, 2016  10:07 PM
+
+> So, if a term needs to be invented, fine, but please not "reentrant" and
+> please no "in the sense that". "non-interfering" perhaps, or "race free".
+> 
+
+I agree that reentrant is not the right word. I was just looking for some
+label that we could refer to in other places. I wonder if "race free" might be
+over-promising, that is, I'm not sure the definition guarantees that there are
+no unprotected global variables being referenced by the subprogram. Maybe the
+definition needs to be expanded to cover that case as well.
+
+In the original version of AI 196, I had defined "concurrently-callable",
+which we decided to get rid of, once we thought it could be replaced by the
+"reentrant" definition we had. Now that reentrant is gone, maybe
+concurrently-callable is another option to reconsider. "Non-interfering" also
+seems like a reasonable choice.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, December 24, 2016  8:51 AM
+
+I suspect Randy will be a bit annoyed you didn't mention this issue earlier!
+
+As it is now, AI196 doesn't use "reentrant" in normative wording, so we don't
+really need to define it in the RM.  On the other hand, I agree it might be
+handy to have a word like "non-interfering" available for use, though at least
+as far as AI196, we could define the term in an AARM annotation.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Saturday, December 24, 2016  10:28 AM
+
+> I suspect Randy will be a bit annoyed you didn't mention this issue 
+> earlier!
+
+I suspect so also, but I honestly didn't think of this until yesterday. 
+I was about to approve. So probably the synapses would have fired sooner if I
+hadn't procrastinated until now to put my X somewhere on the ballot.
+
+But I think trying to apply a label to this is illuminating. Erhard's
+suggestion to use "race-free" actually sounds like what we really want, but
+that points out that we are missing some details in our definition about
+also ensuring there are no modifications to unprotected global variables.
+
+This seems useful also for amendment AI12-0079 on the global aspect, though
+that is farther off in the future.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, December 27, 2016  9:40 PM
+
+> I suspect Randy will be a bit annoyed you didn't mention this issue 
+> earlier!
+
+I would have been, but luckily his vote doesn't matter.
+
+The vote was Approve (with or without changes): Baird, Barnes, Brukardt,
+Burns, Cousins, Dismukes, Ploedereder, Rosen, Taft, and Vardanega.
+
+Reject: Moore.
+
+Abstain: Duff.
+
+Thus we have a vote of 10-1-1. Given our new procedures, we require a majority
+of the responding members (12 here) to vote for it (that would mean at least 7
+approve votes in this case); and no more than 17% rejection votes (that's 2.04
+votes in this case). All of these are clearly met, so this vote (to approve
+AI12-0200-1) passes.
+ 
+> As it is now, AI196 doesn't use "reentrant" in normative wording, so 
+> we don't really need to define it in the RM.  On the other hand, I 
+> agree it might be handy to have a word like "non-interfering" 
+> available for use, though at least as far as AI196, we could define 
+> the term in an AARM annotation.
+
+Right, it just changes the AARM notes, which don't require any formal action.
+And those notes really don't need a term, as it is primarily used to identify
+the rules in question. The problem being that just identifying them as the
+rules in A isn't very helpful. There's a reason that the drafting rules for
+Standards do not allow text in places like the header of an Annex!
+(And also why we never put any rules in such places except these rules in
+Annex A.)
+
+I guess it is a big editorial review update, but since nothing normative needs
+to be changed, we don't need to vote on either of these again.
+
+In any case, this is a problem with AI12-0196-1, not with AI12-0200-1, so
+Brad's vote is misplaced. (I filed this thread on AI12-0196-1).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, December 27, 2016  8:51 PM
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent