Re: an error in Re: tasking

[franke@minet.uni-jena.de (Frank Ecke)]

On 7 Oct 1998 16:51:45 GMT, Frank Ecke <franke@minet.uni-jena.de> wrote:

>    Note further that if Do_Some_Stuff_Here were part of the accept statement
> corresponding to the Start entry, it would be executed as part of an abort-
> deferred operation, namely the rendezvous between the caller and the callee,
> and could thus not be aborted.

Unfortunately, this is incorrect.  The rendezvous is not an abort-deferred
operation.  But the whole truth is way more sophisticated.  Consider a 3-task
system: a server, a client, and another task T.  Let the client be engaged in
rendezvous (which involves no abort-deferred operation whatsoever) with the
server.  Now if T aborts the server, the client receives Tasking_Error---that
is, the server, in the midst of executing the critical rendezvous (imagine a
database transaction), is relentlessly aborted and the rendezvous is abruptly
terminated.  The database might by inconsistent now.

   On The other hand, if T aborts the client, then the server is not affected;
the rendezvous carries on to completion with the client in a somewhat abnormal
state and it is only when the rendezvous is complete that client becomes
properly completed.  The rationale for this is simple; if the client asks for a
service and the server dies so that the service cannot be provided, then the
client should be told.  On the other hand, if the client dies, too bad---but we
must avoid upsetting the server which might have the database in a critical
state.

   The rendezvous is thus an example of an abort-deferred operation for the
client (not for the server).

[adopted with slight modifications from Barnes' ``Programming in Ada 95'',
page 426--427]

   Now comes the fun part.  Let us look at ATC (asynchronous transfer of
control).  Assume the client issues

   select
      Server.Entry_Call;
      -- optional sequence of statements
   then abort
      -- the abortable part
   end select;

at a time when the server is not in a position to handle Entry_Call.  This call
is thus queued and the abortable part is executed.  Now, whilst the abortable
part is being executed, the server reaches an accept for Entry_Call and
executes the corresponding sequence of statements.  Let the abortable part
complete prior to the completion of the triggering entry call.  In this case,
``an attempt to cancel the triggering_statement is made.'' (ARM, 9.7.4[8])
However, as (ARM, 9.5.3[20]) states, ``the cancellation does not take place
until a point (if any) when the call is on some entry queue, and not protected
from cancellation as part of a requeue (see 9.5.4); at such a point, the call
is removed from the entry queue and the call completes due to the
cancellation.''  If the accept Entry_Call does not include a requeue (with
abort), then it is not possible, in our example, to abort the triggering
statement---the rendezvous carries on to completion and is thus an abort-
deferred operation for the server.  The optional sequence of statements is
executed.

   Of course, there is a difference between aborting a task and aborting a
sequence of statements but I had no idea that it is this subtle.

The rationale for Ada states in 9.5, ``The Abort Statement'': 

:: In Ada 95, it is essential that use of the abort statement, and, more
:: importantly, the asynchronous select statement with its abortable part, not
:: result in corruption of global data structures.  In Ada 83, abort was
:: deferred for a calling task while it was engaged in a rendezvous.  This
:: allowed the rendezvous to complete normally so that the data structures
:: managed by the accepting task were not left in an indeterminate state just
:: because one of its callers was aborted.

:: For Ada 95, we have generalized this deferral of abort to include the time
:: during which calls on protected operations are being serviced, and the
:: initialization, assignment and finalization of controlled types (see 7.4).
:: (However, we recall that requeue with abort allows a server to override
:: deferral if desired as explained in 9.2.)

:: Without deferral of abort, any update of a global data structure becomes
:: extremely unsafe, if not impossible.

Very well, but why is a rendezvous not an abort-deferring operation when the
server is aborted?  Or, to be more precise, why is the rendezvous treated
differently in the case of aborting a task that executes an accept statement
and in the case of aborting the triggering entry call in the ATC statement?

   After all, it is the server that manipulates the global data structures and
aborting it creates the mess.


I hope someone can shed some light on these issues.


Frank

--
Frank Ecke <franke@minet.uni-jena.de>


       In a world without walls and fences, who needs windows and gates?