AI22-0058-2
!standard D.2.6(29/2) 23-06-29 AI22-0058-2/02
!standard D.2.6(29/2)
!standard D.5.1(12)
!class Ramification 22-01-11
!status WG9 Approved 23-10-12
!status ARG Approved 8-0-0 23-06-12
!status work item 23-06-11
!status received 23-06-11
!submitter Niklas Holsti
!priority Low
!difficulty Easy
!subject Wording for checking Task_Ids
Fixes for wording involving task id parameters to real-time subprograms.
Some wording relating to checking task ids doesn't make sense.
Make AARM changes to clarify the order of certain checks on task ids.
Add after D.2.6(29/2):
AARM To Be Honest: One has to check whether T is Null_Task_Id before checking whether T is terminated.
[Editor's note: It could make sense to add this after other similar wording: D.5.1(9), D.11(8), D.14(17/2), D.14.2(33/2).]
Modify AARM D.5.1(12.a):
Note that this rule overrides the above rule saying that {Tasking_Error}[Program_Error] is raised on Get_Priority of a terminated task. If the task object still exists, and the task is terminated, Get_Priority raises {Tasking_Error}[Program_Error]. However, if the task object no longer exists, calling Get_Priority causes erroneous execution.
While it would be appealing to define this check as a Precondition, that would introduce a race condition. A task could become terminated between the evaluation of the precondition and the actual use within the subprogram. Thus, a precondition is inappropriate for these routines.
One could use a precondition for the Null_Task_Id check, but that seems to have insufficient value to change in the absence of a more general overhaul of routines.
The normative wording implies that you have to check for termination before checking for Null_Task_Id. That seems backwards, as you cannot check any properties of a task that isn't a task at all. However, the normative wording seems insufficiently broken; the two conditions can be considered disjoint so the order doesn't need to be defined in the abstract. (In practice, that is different, of course.)
No semantic change is intended, so existing tests (if they exist) should cover this case.
This AI was promoted from AI12-0316-1 to be reconsidered for post-Ada 2022 work. The !appendix of the original AI has additional motivation and discussion.
The first version of this AI was rewritten to use the suggestion from Randy Brukardt of February 26, 2019 to simplify the change and overcome objections raised during Meeting #60D.
From: Niklas Holsti
Sent: Sunday, June 04, 2023 12:58 PM (WG 9 List)
After reviewing these AIs I have some comments on four of them ...
[Editor’s note: We only include the relevant discussion here, and in the following messages.]
Changing from a prose rule to a precondition introduces a race
condition: the task in question might terminate after the precondition is checked, but before the operation actually tries to operate on the task. In that case the precondition check would pass, but still the operation should fail, reasonably by propagating Tasking_Error.
So while a precondition works for checking that the given Task_Id is not Null_Task_Id, I don't think it works well for checking if the task is terminated, and I propose rejecting that part of the AI.
Note that 6.1.1(34/5) says that in a call on a protected operation the precondition checks are done before starting the protected action, suggesting that an implementation that implements these tasking operations as protected operations would necessarily suffer from this race condition.
If a precondition is preferred also for the termination check there should be an Implementation Requirement that forbids the race condition, but that seems a strange hack.
By the way, there seems to be a minor error in D.5.1(12.a): it says that Get_Priority raises Program_Error if the task still exists but is terminated, while D.5.1(8) says that Tasking_Error is raised in that case, which seems to be correct (also from what is said in this AI).
From: Tucker Taft
Sent: Monday, June 05, 2023 11:53 AM (WG 9 List)
>Changing from a prose rule to a precondition introduces a race
>condition: the task in question might terminate after the precondition
>is checked, but before the operation actually tries to operate on the
>task. In that case the precondition check would pass, but still the
>operation should fail, reasonably by propagating Tasking_Error.
>So while a precondition works for checking that the given Task_Id is not
>Null_Task_Id, I don't think it works well for checking if the task is
>terminated, and I propose rejecting that part of the AI.
Good point. I agree with your logic. It is reminiscent of the problem of trying to use a precondition to detect that a Name_Error is going to be raised by an Open file operation. Clearly the file might be deleted or created in the period between evaluating the preconditions and actually attempting to open the file. So preconditions are inappropriate for anything that involves independent threads of control.
[Editor’s note: Tucker quoted the rest of the note and said “Agreed.”, twice..]
From: Randy Brukardt
Sent: Tuesday, June 06, 2023 1:45 AM (WG 9 List)
WG 9 is not the place to work out anything technical, so anything that can't be cast as an editorial review causes the AI to be withdrawn from the WG 9 approval list.
Clearly, that needs to be done with AI22-0058-1/03 -- Preconditions for checking Task_Ids. ...
From: Randy Brukardt
Sent: Thursday, June 29, 2023 2:00 AM
Since this AI only changes AARM notes, it should be classified as a Ramification rather than a Binding Interpretation (which changes normative wording). I’ve made this change as part of my Editorial Review.