From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3089024a3e433566 X-Google-Attributes: gid103376,public From: franke@minet.uni-jena.de (Frank Ecke) Subject: Re: an error in Re: tasking Date: 1998/10/08 Message-ID: #1/1 X-Deja-AN: 398926082 References: <361B31AA.6714@ipnsun5.in2p3.fr> <361B3260.7475@ipnsun5.in2p3.fr> Organization: Department of Computer Science, FSU Jena, Germany Reply-To: franke@minet.uni-jena.de Newsgroups: comp.lang.ada Date: 1998-10-08T00:00:00+00:00 List-Id: On 7 Oct 1998 16:51:45 GMT, Frank Ecke 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 In a world without walls and fences, who needs windows and gates?