Remove restriction from 9.7.1(12) (mutually exclusive terminate/delay/else) and rework 9.7.1(8) (at least one accept_alternative)

[liampwll]

Since Ada 83, section 9.7.1 has contained the following lines:

8. A selective_accept shall contain at least one accept_alternative. In addition, it can contain:
9. • a terminate_alternative (only one); or
10. • one or more delay_alternatives; or
11. • an else part (the reserved word else followed by a sequence_of_statements).
12. These three possibilities are mutually exclusive.

The rationale does not present a reason for the final condition, unless I have missed it, and I can not think of any obvious reason for this restriction so I would like to propose that those lines are changed to something similar to the following:

8. A selective_accept shall contain at least one may contain multiple accept_alternative. In addition, it can contain:
9. • a terminate_alternative (only one); or
10. • one or more delay_alternatives; or
11. • an else part (the reserved word else followed by a sequence_of_statements).
12. These three possibilities are not mutually exclusive.

The rationale for this change is to allow tasks to define termination points without the need for an accept alternative designed solely to terminate the task. This is especially useful for long-running tasks that perform work in a loop, for example:

task body Server is
begin
   loop
      select
         delay 1.0;
         Update_Temperature_Reading;
      or
         terminate;
      end select;
   end loop;
end Server;

[sttaft]

I understand your interest in providing a way for a task to terminate when all other tasks have terminated, but you would need to carefully define how the various "special" alternatives relate to one another. In particular, it is unclear how an "else" alternative would be useful when combined with a delay alternative. Or for that matter, if every task is in a similar delay-based loop, what would trigger the "group" termination, since delay alternatives will always eventually "succeed."

It would help if you had more complete examples, showing multiple tasks and how the terminate alternative is supposed to work in various situations.

[jprosen]

More precisely, (and this is how I explain it in my courses):

• It makes no sense to have one (or more) delay alternatives together with an else part, since the else part would always be (immediately) selected
• It makes no sense to have a terminate alternative together with an else or delay alternatives, since there is a possibility for the task to resume executing, and therefore the terminate alternative cannot be selected.

QED. Providing two of these alternatives is necessarily a design error, therefore it is best to disallow it.

[liampwll]

I did not consider the interaction between delay and else, those should remain mutually exclusive. As for the case where multiple tasks have delay loops, I think the best option is to add the following to 9.3 or 9.7.1:

If a selective_accept contains one or more delay_alternatives and a terminate_alternative then the terminate_alternative is selected if the master is completed, taking precedence over any delay_alternatives.

It may also make sense to add an Independent_Termination aspect which can be applied to task types to explicitly opt-in to this behaviour.

Lastly it may simplify things if a selective_accept does not allow for any accept_alternatives when both a delay_alternative and terminate_alternative are present.

[jprosen]

You may be in a situation where all tasks that depend on a given master are on a select-with-terminate (hence allowing termination), but if you select the delay alternative, the task wakes up and calls entries on other tasks depending on the same master - hence reviving the whole system. Both would be consistent. How could you choose?
The only case I can imagine where it would make some sense is if you had guards on the delay(s) and terminate alternatives, and these guards would be exclusive (i.e. allowing the programmer to choose between delay and terminate). But I think that putting a rule allowing this case would be way too complicated for a very niche usage.

[liampwll]

That's not an issue as long as the terminate alternative is always selected for a completed master, regardless of what the other alternatives may do. There would have to be a way to do that without surprising the programmer, which is why I presented the option of having an aspect that opts in to this behaviour.

[liampwll]

Another way to achieve the same thing would be:

task body Server is
begin
   while Master_Not_Completed loop
      delay 1.0;
      Update_Temperature_Reading;
   end loop;
end Server;

As far as I'm aware there's currently no way for a task to reference its master and even if there were there's no attribute to determine if a task is completed, there is only one to determine if it is terminated.

[jprosen]

There is a way to wait for the completion of a task (say T): T declares an entry and never accepts it. The other task calls this entry (possibly in a select with else); if T is completed, the other task receives Tasking_Error.
And if a task is completed but not terminated, 'CALLABLE is false and 'TERMINATED is false.

[liampwll]

That gets us most of the way there but still doesn't give a way for a task to reference its master without the programmer explicitly passing in the task ID. So perhaps the best way to address the above usecase is to add a 'Master attribute to tasks.

[liampwll]

Although just a reference to the master task does not help once we start considering elements other than tasks, for example:

procedure Example is
   task type T;

   task body T is
   begin
      loop
         null;
      end loop;
   end T;

   type R is record
      T_Component : T;
   end record;
begin
   declare
      R_Instance : R;
   begin
      delay 5.0;
      Put_Line ("1");
   end; --  Stuck here forever.
   Put_Line ("2"); --  This line is never reached.
end Example;

Obviously this works fine with a terminate as in:

   task type T is
      entry A;
   end T;

   task body T is
   begin
      loop
         select
            accept A;
         or
            terminate;
         end select;
      end loop;
   end T;

However this leaves us no way to perform work in a delay loop without the procedure Example calling the entry.

[jprosen]

Sorry, I miss the point here... Anyway, we have moved away from the original question, so maybe close this topic and possibly open another one. For the 'Master attribute that you suggest, why not? I don't think it would be very useful, but it is a very minor change (anyway, every task has a pointer to its master, so the change to implementations would be minimal).

[liampwll]

As I said, the 'Master attribute does not fully address the original issue because we could be stuck at the end of block rather than the completion of a task, I briefly forgot that this was a possibility.

I will present a more explicit example of how this relates to the original issue. This is what a piece of code might look like with the proposed changes:

procedure Example is
   task type T with Independent_Termination is
      entry Setup;
      entry Start;
   end T;

   task body T is
   begin
      select
         accept Setup;
      or
         terminate;
      end select;

      select
         accept Start;
      or
         terminate;
      end select;

      loop
         select
            delay 1.0;
            Put_Line ("Work done.");
         or
            terminate;
         end select;
      end loop;
   end T;
begin
   declare
      T_Instance : T;
   begin
      T_Instance.Setup;
      T_Instance.Start;
      --  Imagine a more complex program where we might never
      --  call Setup or Start before the end if the scope.

      delay 3.2;
      Put_Line ("End of block.");
   end;
   Put_Line ("Task terminated.");
end Example;

With the proposed changes this code would output:

Work done.
Work done.
Work done.
End of block.
Task terminated.

Currently the cleanest way to achieve this would be to add an entry which exits the loop as shown below. However this adds extra complexity for the programmer over the proposed change. For the first two selects we can of course use a terminate alternative, but the presence of the delay later of forces us to use an entry for all of these as we want to be able to cause the task to exit during any of those selects. We could of course keep track of the state of the task so we know not to call Stop unless we're already in the loop, but this is error-prone, especially for more complex tasks.

procedure Example is
   task type T is
      entry Setup;
      entry Start;
      entry Stop;
   end T;

   task body T is
      Stop_Error : exception;
   begin
      select
         accept Setup;
      or
         accept Stop;
         raise Stop_Error;
      end select;

      select
         accept Start;
      or
         accept Stop;
         raise Stop_Error;
      end select;

      loop
         select
            delay 1.0;
            Put_Line ("Work done.");
         or
            accept Stop;
            raise Stop_Error;
         end select;
      end loop;
   exception
      when Stop_Error =>
         null; --  We want to avoid this looking like a real error.
   end T;
begin
   declare
      T_Instance : T;
   begin
      T_Instance.Setup;
      T_Instance.Start;
      --  Imagine a more complex program where we might never
      --  call Setup or Start before the end if the scope.

      delay 3.2;
      Put_Line ("End of block.");
      T_Instance.Stop;
   end;
   Put_Line ("Task terminated.");
end Example;

[liampwll]

Upon further consideration, the previously proposed Independent_Termination aspect is likely required to make this work in a sane way in all cases. For example, consider the following:

procedure Example is
   task type T with Independent_Termination is
      entry E;
   end T;

   task body T is
      task T_Child with Independent_Termination;

      task body T_Child is
      begin
         loop
            select
               delay 1.0;
            or
               terminate;
            end select;
         end loop;
      end T_Child;
   begin
      null;
      loop
         select
            accept E;
         or
            terminate;
         end select;
      end loop;
   end T;
begin
   declare
      T_Instance : T;
   begin
      delay 3.0;
   end;
end Example;

In this case we want T to be forced in to the termination alternative after 3 seconds as it has the Independent_Termination aspect, which in turn allows T_Child to terminate.