Version 1.1 of ai12s/ai12-0197-2.txt

Unformatted version of ai12s/ai12-0197-2.txt version 1.1
Other versions for file ai12s/ai12-0197-2.txt

!standard 9.1(21)          16-06-12 AI12-0197-2/01
!class Amendment 16-06-07
!status work item 16-06-12
!status received 16-06-12
!priority Medium
!difficulty Hard
!qualifier Amendment
!subject Passive tasks
!summary
Aspect Passive is added to tasks (and task types)
!question
Tasks are often a nice and readable model to express operations where state is kept as the place in execution, such as generators, couroutines, etc. However, using plain tasks involve efficiency costs due to task switching and raises scheduling issues. Should it be possible to express behaviour in a task-like fashion, while being executed by the caller of provided services ? (Yes)
!recommendation
Add a "passive" aspect to tasks and task types, specifying that the task has no thread of its own, but that its code is to be executed by client tasks when necessary.
!wording
!discussion
There is no thread of control associated to a passive task. The model is that when a client task calls an entry of a server task, the code of the server task is executed "by proxy" by the caller task (similar to the proxy model of protected actions). This involves stack switching, but no task switching. All scheduling properties remain those of the client task.
The client task will execute the server code up to the point where it returns from the called entry. There is no restriction to what can be executed while "catching-up".
The rendezvous is considered to start as soon as the client calls the entry (therefore including while catching-up). A consequence of this is that abort is deferred for the client, and that changes to the waiting queue for the entry (like reordering due to changes of priority, f.e.) do not affect the behaviour. On the other hand, if the server task is aborted, execution of the server code is aborted and the client receives Tasking_Error, as expected.
This model provides a kind of lazy evaluation and saves the task switching cost. As it is purely sequential, ordering of actions is well defined (at least between client and server).
An implementation permission should be provided to ignore the "passive" aspect. The main difference if the aspect is ignored is for the scheduling aspects of the server task (including possible ordering of actions).
!ASIS
!ACATS test
!appendix

From: Jean-Pierre Rosen
Sent: Sunday, June 12, 2016  5:53 AM

Here is a first shot at what I had in mind about passive tasks.

Wait while I get my asbestos suit...

****************************************************************

Questions? Ask the ACAA Technical Agent