CVS difference for 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.
+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.
+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,
+ with Global => (In_Out => Synchronized),
+ Potentially_Blocking => False
+ procedure Do_Something (X : in out T;
+ Y : in U);
+ function Query_Something (A : T)
+ return Z;
+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