!topic LSN on ATC Simplifications
!key LSN-1049 on ATC Simplifications
!reference MS-9.9.4;4.6
!reference MS-9.12;4.6
!reference LSN-026
!from Bob Duff $Date: 92/10/14 14:25:07 $ $Revision: 1.3 $
!discussion

This Language Study Note discusses certain simplifications of the
asynchronous transfer of control (ATC) facility of Ada 9X.

The consensus at the Frankfurt WG9 meeting in April was that ATC should
be in the language, but that the MRT should try to simplify it as much
as possible.  One specific concern was that we should make sure it is
feasible to support the "two thread" implementation model, which has
been proposed by Brian Dobbing (in addition to other implementation
techniques, of course).

ATC is now required to have only one "trigger", since multi-way entry
call has been removed from the language.  This makes efficient
implementations easier.  Multiple triggers might impose extra overhead
between an event an the response.

We intend to disallow accept statements within the abortable part.

In Ada 83, if a task calls an entry, and gets TASKING_ERROR, it means
that the target task is dead, or soon will be.  We believe that it is
important to preserve this property.  If accept statements were allowed
inside an abortable part, this property would no longer be true.

Furthermore, this restriction is helpful in making the two-thread
implementation technique work.  The thread that represents the abortable
part should not have to accept entry calls on behalf of the other
thread.


NESTING.

It has been suggested that part of the complexity of ATC comes from
the ability to nest ATC, which implies that a given task can be on
more than one queue at a time.  We disagree, and have decided to
retain the ability to nest, for the following reasons:

    - It is not the nesting of ATC within ATC that causes multiple queuing.
      Instead, it is the nesting of anything that causes queuing.
      In particular, if the abortable part does an entry call, the
      task will be on two queues at once.  We do not wish to disallow
      entry calls in an abortable part, because that would make the
      feature almost useless.  For example, in the "mode change"
      examples of the Rationale, the abortable part contains most of
      the code of the task, and forbidding entry calls would essentially
      forbid all inter-task communication!

    - Implementers have stated that the complexity they had originally
      associated with multiple queuing was not really a serious problem.
      Threading the queue links through a stack-allocated "queue
      element" is not really very difficult.

    - If the two-thread model of ATC is used, then each thread is
      only on one queue at a time, no matter what is nested within
      the abortable part.  That's because the abortable part is a
      separate thread.  Therefore, there is no multiple-queuing
      problem.

    - Disallowing certain things within an abortable part would
      cause distributed overhead, because it cannot be detected
      at compile time (unless we were to go so far as to forbid
      subprogram calls!).  For an entry call, we do not want even
      the little bit of overhead to check whether we are currently
      in an abortable part.


DISTRIBUTED OVERHEAD.

One of the U/I teams (Tartan) has designed ATC in a way that does
not involve distributed overhead.


SUMMARY.

We believe we have simplified ATC sufficiently to allow
implementations that have rapid response to ATC, and that
do not have distributed overhead on other features of the
language.  Implementations are free to choose the two-thread
model, or the implementation model originally proposed by the MRT.