Re: Ada Protected Object Turorial #2: Overview of Tasks

[Robert Dewar <dewar@gnat.com>]

In article <83hu2h$bba$1@bgtnsc01.worldnet.att.net>,
  "James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote:

> declare
>    Database_Txn : Transaction;
>    -- declare a transaction, commit or abort during
>    -- finalization
> begin
>    select
>       -- wait for a cancel key from the input device
>       Input_Device.Wait_For_Cancel;
>       -- the Satus remains Incomplets, so that the transaction
>       -- will not commit
>    then abort
>       -- do the transaction
>       Read(Database_Txn, ...);
>       Write(Database_Txn, ...);
>        ...
>        Set_Status(Database_Txn, Succeeded);
>        -- set status to ensure the transaction is committed
>    end select;
>    -- Finialize of Database_Txn will be called here and,
>    -- based on the recorded status, will either commit or
>    -- abort the transaction.
> end;


The above is in fact a good example of how dangerous ATC can
be. In order to program in this manner, the entire database
update operation must be made abort safe. This is really tricky
to do, especially in the light of allowed 11.6 optimizations.
In practice it will be necessary to defer aborts at critical
points, but the language only offers kludgy ways to do this in
a general manner:

  a) use a protected type, but then you have to worry about not
     doing potentially blocking operations.

  b) introduce arbitrary finalization handlers and do things as
     bogus finalization steps.

In GNAT, you can use pragma Abort_Defer, which is far cleaner
but implementation dependent. We introduced this pragma because
it really seems that without it you can't use AST reasonably
at all, and there are other situations where deferring abort
is preferable. In general it is far easier to defer an abort
than take it and then desparately try to undo the ill effects
in a finalization handler, not knowing exactly what has and
has not actually been done at the point of the abort. Yes of
course you can fragment the operation into steps with a
finalization handler for each step, but even this is tricky,
especially since it requires a kludge to get a simple
finalization handler for a block of code (have to declare a
bogus controlled object)

All in all, a good rule in Ada 95 is not to use ATC. I know
that I generally say that any rule saying "don't use feature
X" is a mistake since the feature would not be in the language
unless it had been carefully thought out and understood to
be useful. However, in my opinion [not new, I strongly opposed
adding this feature] ATC is NOT a desirable feature in Ada :-)

I just trimmed this to CLA, since it is rather too Ada specific
for comp.threads.

Robert Dewar


Sent via Deja.com http://www.deja.com/
Before you buy.