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

Differences between 1.9 and version 1.10
Log of other versions for file ai12s/ai12-0267-1.txt

--- ai12s/ai12-0267-1.txt	2018/11/20 07:09:39	1.9
+++ ai12s/ai12-0267-1.txt	2018/12/02 08:13:18	1.10
@@ -1,9 +1,7 @@
-!standard 5.1(1)                                      18-11-19  AI12-0267-1/07
-!standard 9.5(57/5)
+!standard 9.5(57/5)                                     18-11-19  AI12-0267-1/07
 !standard 9.10(11)
 !standard 9.10(15)
-!standard 11.5(19.2/2)
-!standard H.5(0)
+!standard 9.10.1(0)
 !standard H.5(1/2)
 !standard H.5(5/5)
 !standard H.5(6/2)
@@ -147,7 +145,7 @@
 
     Syntax
 
-  The form of a Conflict_Check_Policy pragma is as follows:
+  The form of a pragma Conflict_Check_Policy is as follows:
 
     pragma Conflict_Check_Policy (/policy_/identifier);
 
@@ -291,15 +289,183 @@
 is to an element of an array using either the loop parameter or
 the chunk index as the index into the array.
 
+!corrigendum 9.5(17/3)
+
+@drepl
+A large block of insertions; just enough to force a conflict.
+@dby
+A {parallel construct or a} nonblocking program unit shall not
+contain, other than within nested units with Nonblocking specified as
+statically False, a call on a callable entity for which the
+Nonblocking aspect is statically False, nor shall it contain any of
+the following:
+
+!corrigendum 9.10(11)
+
+@drepl
+@s8<@i<Erroneous Execution>>
+
+Given an action of assigning to an object, and an action of reading 
+or updating a part of the same object (or of a neighboring object if 
+the two are not independently addressable), then the execution of the 
+actions is erroneous unless the actions are @i<sequential>. Two actions
+are sequential if one of the following is true: 
+@dby
+Two actions
+are defined to be @i<sequential> if one of the following is true:
+
+!corrigendum 9.10(15)
+
+@drepl
+Aspect Atomic or aspect Atomic_Components may also be specified to ensure 
+that certain reads and updates are sequential @emdash see C.6. 
+@dby
+Two actions that are not sequential are defined to be @i<concurrent>
+actions.
+
+Two actions are defined to @i<conflict> if one action assigns to an
+object, and the other action reads or assigns to a part of the same
+object (or of a neighboring object if the two are not independently
+addressable).  The action comprising a call on a subprogram or an
+entry is defined to @i<potentially conflict> with another action if the
+Global aspect (or Global'Class aspect in the case of a dispatching
+call) of the called subprogram or entry is such that a conflicting
+action would be possible during the execution of the call. Similarly
+two calls are considered to potentially conflict if they each have
+Global (or Global'Class in the case of a dispatching call) aspects
+such that conflicting actions would be possible during the execution
+of the calls.
+
+A @i<synchronized> object is an object of a task or protected type, an
+atomic object (see C.6), a suspension object (see D.10), or a
+synchronous barrier (see D.10.1). Operations on such
+objects are necessarily sequential with respect to one another, and
+hence are never considered to conflict.
+
+@s8<@i<Erroneous Execution>>
+
+The execution of two concurrent actions is erroneous if the actions make
+conflicting uses of a shared variable (or neighboring variables that are
+not independently addressable).
+
+!corrigendum 9.10.1(0)
+
+@dinsc
+
+This subclause determines what checks are performed relating to possible
+concurrent conflicting actions (see 9.10).
+
+@s8<@i<Syntax>>
+
+The form of a @fa<pragma> Conflict_Check_Policy is as follows:
+
+  @xcode<@ft<@b<pragma> Conflict_Check_Policy(@i<policy_>>@fa<identifier>@ft<);>>
+
+A @fa<pragma> Conflict_Check_Policy is allowed only immediately within a
+@fa<declarative_part>, a @fa<package_specification>, or as a configuration pragma.
+
+@s8<@i<Legality Rules>>
+
+The @i<policy_>@fa<identifier> shall be one of Unchecked, Known_Conflict_Checks,
+Parallel_Conflict_Checks, All_Conflict_Checks, or an implementation-defined
+conflict check policy.
+
+A @fa<pragma> Conflict_Check_Policy given in a @fa<declarative_part> or
+immediately within a @fa<package_specification> applies from the place of
+the pragma to the end of the innermost enclosing declarative region.
+The region for a @fa<pragma> Conflict_Check_Policy given as a configuration
+pragma is the declarative region for the entire compilation unit (or
+units) to which it applies.
+
+If a @fa<pragma> Conflict_Check_Policy applies to a @fa<generic_instantiation>,
+then the @fa<pragma> Conflict_Check_Policy applies to the entire instance.
+
+If multiple Conflict_Check_Policy pragmas apply to a given
+construct, the conflict check policy is determined by the one in the
+innermost enclosing region. If no such Conflict_Check_Policy pragma exists,
+the policy is Parallel_Conflict_Checks (see below).
+
+Certain potentially conflicting actions are disallowed according to which
+conflict check policies apply at the place where the action or actions 
+occur, as follows:
+
+@xhang<@xterm<Unchecked>
+This policy imposes no restrictions.>
+
+@xhang<@xterm<Known_Conflict_Checks>
+If this policy applies to two concurrent actions occuring within the 
+same compilation unit, they are
+disallowed if they are known to denote the same object (see 6.4.1)
+with uses that potentially conflict. For the purposes of this
+check, any parallel loop may be presumed to involve multiple
+concurrent iterations, and any named task type may be presumed to have
+multiple instances.>
+
+@xhang<@xterm<Parallel_Conflict_Checks>
+This policy includes the restrictions imposed by the
+Known_Conflict_Checks policy, and in addition disallows a parallel 
+construct from reading or updating a variable that is global to the 
+construct, unless it is a synchronized object, or unless the construct 
+is a parallel loop, and the global variable is a part of a component of
+an array denoted by an indexed component with at least one index 
+expression that statically denotes the loop parameter of the
+@fa<loop_parameter_specification> or the chunk parameter of the
+parallel loop.>
+
+@xhang<@xterm<All_Conflict_Checks>
+This policy includes the restrictions imposed by the
+Parallel_Conflict_Checks policy, and in addition disallows a task
+body from reading or updating a variable that is global to the task
+body, unless it is a synchronized object.>
+
+@s8<@i<Implementation Permissions>>
+
+When the applicable conflict check policy is Known_Conflict_Checks, the
+implementation may disallow two concurrent actions if the
+implementation can prove they will at run-time denote the same object
+with uses that potentially conflict.
+
+!corrigendum H.5(1/2)
+
+@drepl
+The following @fa<pragma> forces an implementation to detect potentially
+blocking operations within a protected operation.
+@dby
+The following @fa<pragma> requires an implementation to detect potentially
+blocking operations during the execution of a protected operation or a 
+parallel construct.
+
+!corrigendum H.5(5/5)
+
+@drepl
+An implementation is required to detect a potentially blocking operation during
+a protected operation, and to raise Program_Error (see 9.5.1). 
+@dby
+An implementation is required to detect a potentially blocking operation that 
+occurs during the execution of a protected operation or a parallel construct 
+defined within a compilation unit to which the pragma applies, and to raise
+Program_Error (see 9.5).
+
+!corrigendum H.5(6/2)
+
+@drepl
+An implementation is allowed to reject a @fa<compilation_unit> if a potentially
+blocking operation is present directly within an @fa<entry_body> or the body of
+a protected subprogram.
+@dby
+An implementation is allowed to reject a @fa<compilation_unit> to which a
+pragma Detect_Blocking applies if a potentially blocking operation is
+present directly within an @fa<entry_body>, the body of a protected
+subprogram, or a parallel construct occurring within the compilation unit.
+
 !ASIS
 
 ** TBD.
 
-
 !ACATS test
 
-ACATS B- and C-Tests are needed to check that the new capabilities are
-supported.
+ACATS B-Tests are needed to check that the new conflict policies are
+supported and enforced.
 
 
 !appendix

Questions? Ask the ACAA Technical Agent