Version 1.3 of ai12s/ai12-0064-1.txt

!standard 9.5.1(18) 13-05-09 AI12-0064-1/01
!class Amendment 13-04-22
!status work item 13-04-22
!status received 13-04-22
!priority Medium
!difficulty Medium
!subject Nonblocking subprograms

During a protected action, it is a bounded error to invoke an operation that is potentially blocking. There is currently no mechanism (other than a comment) to specify that a given subprogram is intended to be safely callable during a protected action (i.e., that the subprogram will not invoke an operation that is potentially blocking). This seems like a useful part of a subprogram's "contract" that should be (optionally) specifiable at the point of a subprogram's declaration.

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 expression. [This aspect is never inherited;] if not directly specified, the aspect is False.

When a callable entity is nonblocking, a call to the entity is considered to be within a protected operation for purposes of the check described above that is associated with invoking an operation that is potentially blocking (including interactions with pragma Detect_Blocking (see H.5)). In addition, a call to an entity that is not a nonblocking entity is considered potentially blocking for the purposes of the check.

AARM Ramification: This implies, if Detect_Blocking is set, that calling a potentially blocking operation from the body of Nonblocking subprogram raises Program_Error. That includes calling any non-nonblocking subprograms.

AARM Implementation Note: We make calling non-nonblocking subprograms from the body of a nonblocking subprogram a bounded error so that the check can be made statically in the case that pragma Detect_Blocking is in force. We certainly do not want distributed overhead in the case where pragma Detect_Blocking is in force, a nonblocking subprogram that is called from outside of a protected action then calls a normal subprogram that uses a potentially blocking operation (this case would require an extra TCB flag or the like to be reliably detected, which is required in the presence of the pragma).

A subprogram shall be nonblocking if it overrides a dispatching nonblocking procedure. In addition to the places where Legality Rules normally apply (see 12.3), this rule applies also in the private part of an instance of a generic unit.

We've modeled this aspect after No_Return, which has a similar purpose and presumably has already worked out the needed rules.

For this reason, we don't have nonblocking access-to-subprogram types. One could imagine such a thing, but it would take a number of additional rules and certainly wouldn't be "keeping it simple".

The rules do not allow calling "normal" subprograms from a nonblocking subprogram. This allows detecting any potentially blocking operations used in a nonblocking subprogram statically. This is important if pragma Detect_Blocking is used, as such detection is required. (Otherwise, this is just a bounded error and the "mistake" can be ignored with the usual consequences.)

function Creator (Index : Worker_Indexes) return Worker is begin return Result : Worker (Index); end Creator;

All of these tasks will be activated together, and they will know their position in the array (so that they can communicate directly with the neighbors) without needing an initialization entry call (which necessarily would serialize the starting of the tasks).