tasking

tasking

[grave]

Hi,

I'm wanting to kill a task to let an exception propagate and kill the
process. How can I do this if the task is already excuting some part of
code like this :

select
   entry start;
   
or
   terminate;
end select;

Here I'm wanting to kill the task when it works in Do_Some_Stuff_Here;

Is this possible ?

an error in Re: tasking

[grave]

I've deleted a little part of the previous post. Sorry.

> Hi,
> 
> I'm wanting to kill a task to let an exception propagate and kill the
> process. How can I do this if the task is already excuting some part of
> code like this :
> 
> select
>    entry start;
>    Do_Some_Stuff_Here;
> or
>    terminate;
> end select;
> 
> Here I'm wanting to kill the task when it works in Do_Some_Stuff_Here;
> 
> Is this possible ?

Re: an error in Re: tasking

[Frank Ecke]

On Wed, 07 Oct 1998 11:20:32 +0200, grave <grave@ipnsun5.in2p3.fr> wrote:

> I'm wanting to kill a task to let an exception propagate and kill the
> process.  How can I do this if the task is already excuting some part of
> code like this :
> 
> select
>    entry start;
>    Do_Some_Stuff_Here;
> or
>    terminate;
> end select;
> 
> Here I'm wanting to kill the task when it works in Do_Some_Stuff_Here;
> 
> Is this possible ?


You select should read

   select
      accept Start;
      Do_Some_Stuff_Here;
   or
      terminate;
   end select;

for it is not possible to declare an entry within a branch of a select
statement.

   To kill (or abort) a task, use ``abort Task_Name {, Task_Name};'' (see
ARM 9.8).  In order to abort the task from within Do_Some_Stuff_Here (i.e., to
let that task kill itself), you may issue

   Self : Ada.Task_Identification.Task_ID :=
     Ada.Task_Identification.Current_Task;

   ...

   Ada.Task_Identification.Abort_Task(Self);

   Note that trying to kill the task (from outside) ``when it works in
Do_Some_Stuff_Here'' gives raise to a race condition since you cannot be sure
that the task to be killed is already (or still) inside Do_Some_Stuff_Here when
you issue the abort.

   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.

> I'm wanting to kill a task to let an exception propagate and kill the
> process.

I am a bit puzzled by this statement.  Could you please give further
explanations?


Frank

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


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

Re: an error in Re: tasking

[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?

Re: an error in Re: tasking

[Robert A Duff]

franke@minet.uni-jena.de (Frank Ecke) writes:

> 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?

The triggering call in an ATC is usually something pretty short.  If you
attempt to cancel it, and it's already started, it seems to make sense
to let it go.  But aborting a whole server task seems different -- you
want to kill it, and notify callers.

Can you give a more concrete example of where you see the problem?

Note that entry bodies are abort-deferred, whereas accept statements are
not.  Hmm.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: an error in Re: tasking

[Tucker Taft]

Frank Ecke (franke@minet.uni-jena.de) wrote:
: ...
: 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.

The rendezvous model is that a server doesn't manipulate global data
structures.  They manipulate their *own* data structures.
In other words, the server is "global," the data structures are
internal to the server.

So if you abort the server, then there is nothing to protect,
since the data structures are internal to the server.

Aborting this kind of server task is analogous to doing an
unchecked deallocation on an object.  You had better do it
only when you have no further interest in the object.

There are other interesting models, where there are multiple
server tasks, all sharing a common data structure.  In Ada 83,
the only way to do this would have been to have yet another task,
which all the server tasks communicated with, which managed this
shared common data structure.  In Ada 95, this shared common
data structure could be a protected object.

In either model, the actual manipulation of the shared common
data structure by the multiple servers would be abort-deferred,
because it would be implemented by entry (or protected) *calls* 
on the shared common data object/task, not on *accepts.*

In almost any conceivable use of rendezvous, the accept statement
is the time when the acceptor updates its own *internal* data
structures, and communicates with the caller.  It is not the
time when it manipulates some shared global data structure
(unless there is a nested entry/protected call inside the accept statement,
which again would be abort-deferred).

: I hope someone can shed some light on these issues.

See above.

: Frank

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

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: an error in Re: tasking

[Frank Ecke]

On Fri, 16 Oct 1998, Tucker Taft <stt@houdini.camb.inmet.com> wrote:

> 
> The rendezvous model is that a server doesn't manipulate global data
> structures.  They manipulate their *own* data structures.
> In other words, the server is "global," the data structures are
> internal to the server.
> 
> So if you abort the server, then there is nothing to protect,
> since the data structures are internal to the server.
>
> [...]

Yes, that clarifies the matter, thank you!


Frank [scratching his head and nodding]

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


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