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

Differences between 1.4 and version 1.5
Log of other versions for file ai12s/ai12-0064-1.txt

--- ai12s/ai12-0064-1.txt	2013/11/13 01:20:42	1.4
+++ ai12s/ai12-0064-1.txt	2014/10/07 04:39:14	1.5
@@ -29,7 +29,7 @@
 
   For a callable entity or a generic subprogram, the following
   language-defined representation aspect may be specified:
- 
+
       The type of aspect Nonblocking is Boolean. When aspect Nonblocking is
       True for an entity, the entity is said to be nonblocking.
       If directly specified, the aspect_definition shall be a static
@@ -94,5 +94,59 @@
 ACATS B-Tests (to test 4.3.3(17-18) and the new rules) and C-Tests.
 
 !appendix
+
+From: Tucker Taft
+Sent: Monday, October 6, 2014  10:35 AM
+
+Another section of the HILT paper related to a Potentially_Blocking aspect.
+Below is that section.  As Randy and others have pointed out, we would need to
+put a specification of the Potentially_Blocking aspect on each of the existing
+Ada standard library packages, since the default implies blocking.
+
+-Tuck
+----------
+Another important piece of knowledge the caller of a subprogram might need to
+know is whether or not the call is potentially blocking. The Ada language
+defines potentially blocking operations to include select statements, accept
+statements, delay statements, abort statements, and task creation or activation,
+among others. When executing parallel code, potentially blocking operations can
+cause problems such as deadlocks. Currently there is no standard way in Ada to
+specify that a subprogram is potentially blocking. If the compiler cannot
+statically determine that a subprogram call is potentially blocking, the
+programmer has to rely on run-time checking to detect these sorts of problems.
+We propose the addition of a boolean Potentially_Blocking aspect that can be
+applied to subprogram specifications to indicate whether they use constructs
+that are potentially blocking or call other subprograms that have the
+Potentially_Blocking aspect with a value of True. Such an aspect enhances he
+safety of parallel calls, and also generally improves the safety of Ada, since
+it allows the compiler to statically detect more problems involving calls on
+potentially blocking subprograms. The default value for the Potentially_Blocking
+aspect is True.
+
+We also propose that these defaults can be overridden for a package by allowing
+these aspects to be specified at package level, with the meaning that they
+establish a default for all subprograms in the package. For example,
+
+package My_Stuff
+    with Global => (In_Out => Synchronized),
+         Potentially_Blocking => False
+is
+    procedure Do_Something (X : in out T;
+                            Y : in U);
+    function Query_Something (A : T)
+          return Z;
+       ...
+end My_Stuff;
+
+Indicates that all subprograms in package My_Stuff involve access to
+synchronized globals, and all of these calls are not potentially blocking calls
+(in particular these cannot include entry calls, delays, select statements, etc.
+[23, section 9.5.1]). Such an annotation would alleviate the need to repeat the
+Global or Potentially_Blocking aspect on each subprogram, as long as the
+package-level default is appropriate for that subprogram.
+
+In the absence of such an explicit package-wide default, the default for
+Potentially_Blocking would be True, and the default for Global would be (In_Out
+=> all) in a normal package, and null in a declared-pure package.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent