comp.lang.ada
 help / color / mirror / Atom feed
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Asynchronous Transfer of Control
Date: 1996/10/19
Date: 1996-10-19T00:00:00+00:00	[thread overview]
Message-ID: <dewar.845732555@merv> (raw)
In-Reply-To: DzH5n3.2rE@thomsoft.com


Ken said

"Give ObjectAda for Windows a try.  It does preemptive abort without
polling.  It's implemented by suspending the thread, then
resuming it at some run-down code.  For ATC, the run-down code
longjmp's back to the correct place.  For an abort, it finalizes
everything and terminates the thread."

Presumably you only suspend the thread if it is not in an abort deferred
region, but indeed if you have the capability of suspend at an arbitrary
point and resume somewhere else you can do what you want.

Note that ObjectAda is validated for Annex D, the real time Annex, this
tells you right away that it has immediate abort, since that is one of
the requirements. The only deviation is the very reasonable limitation in
the number of priority levels from 31 to 7, to reflect the limitations of
the underlying OS (this actually took quite a bit of argument, there were
some who felt that validation for Annex D should be denied on this basis,
but I and others felt strongly that this is a perfectly reasonable limitation,
and that validation should be allowed, and it was. After all, I think if the
Ada community says "sorry, NT unsuitable for real time with Ada", the rest
of the world is more likely to think "Too bad, Ada unsuitable for real time
with NT!"

Anyway, the bottom line is that if you want to use ATC, you must in pracite
choose a compiler that implements the real time annex, or at least this
critical part of it.

That being said, my advice is NEVER use ATC. As soon as your program can
have asyncrhonous aborts, you have to start worrying EVERYWHERE IN YOUR
PROGRAM about the possibility of a suddent abort occurring and leaving
data in an inconsistent state. This is made worse by the failure in Ada 95
to provide convenient mechanisms for deferring abort.

Consider an example, suppose you have a sorting procedure which may be
called by a thread which may get aborted (note that figuring out the
truth of such a predicate means unwinding all abvstractions in a manner
that one normally does not like to do).

By analyzing these abstractions at various levels, you determine that you
cannot afford to abort defer the entire sort, but will instead simply resume
and complete the sort later if you are aborted. Now, you also decide that
making a copy for such resumption will waste too much time and space for
the normal case where an abort does not occur.

So, you decide to use an exchange sort of some type (e.g. quicksort), where
the data is shuffled, but left intact, providing that each exchange is
abort deferred. 

How do do this?

In standard Ada 95, it means either making the exchange a bogus protected
operation (bogus in the sense that you don't need any of the other semantics
of protected types), or a bogus finalization routine. Both of these mess
up the program, and are far from syntactically trivial. 

In GNAT, you can use the Abort_Defer pragma, but this of course makes your
program potentially less portable unless other vendors implement this
highly useful pragma (highly useful that is if you insist on using ATC).

That's a mess, and this analysis and possible resulting mess has to be
repeated throughout your program.

Now you begin to see why I (and many others) think that ATC should never
have been let into the language.

A common response is, never mind, if you don't want to use it, don't and
then you will be unaffected.

False! When you write a routine to sit in some library, you have no idea
whether or not it will be used in a context allowing Abort. Consequently,
there is substantial overhead from abort defer operations whether or not
you will be using Abort. 

Pragma Restrictions (No_Abort) could help, but is very seldom used in
existing Ada 95 code (a grep of our regression suite shows no use exept
in one test I wrote to specifically test it out!) Furthermore, you really
need a specialized version of the runtime to take full advantage of this,
and indeed Dong-Ik, a student at FSU working with Ted Baker, is working
on understanding how much help such a restricted runtime might be as his
PhD thesis topic, so perhaps we will know more in the near future.

For me, ATC was one of the worst decisions in Ada 95, but this was certainly
energetically argued, and lots of people felt it was essential. It will be
interesting to see who is right in the long run. So far we have had a couple
of customers try to use ATC, and then abandon it when they realized the
consequences. On the other hand, I believe Jim Hopper has an example of
its safe use where it was very helpful. Which is the more typical case?
Time will help to tell.





  parent reply	other threads:[~1996-10-19  0:00 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-10-16  0:00 Asynchronous Transfer of Control James Squire
1996-10-16  0:00 ` Robert Dewar
1996-10-23  0:00   ` James Squire
1996-10-23  0:00     ` Robert Dewar
1996-10-17  0:00 ` Tucker Taft
1996-10-17  0:00   ` Robert A Duff
1996-10-17  0:00     ` Latest /= Greatest (was: Asynchronous Transfer of Control) Larry Kilgallen
1996-10-22  0:00       ` Asynchronous Transfer of Control Dale Stanbrough
1996-10-18  0:00     ` Ken Cowan
1996-10-18  0:00       ` Robert A Duff
1996-10-19  0:00       ` Robert Dewar [this message]
1996-10-21  0:00         ` Philip Brashear
1996-10-21  0:00           ` Robert Dewar
1996-10-21  0:00             ` Larry Kilgallen
1996-10-26  0:00               ` Robert Dewar
1996-10-21  0:00           ` Validation vs. Certification (was: Asynchronous Transfer of Control) Larry Kilgallen
1996-10-22  0:00         ` Asynchronous Transfer of Control Norman H. Cohen
1996-10-21  0:00       ` Pascal Ledru
1996-10-22  0:00     ` Jon S Anthony
1996-10-23  0:00     ` James Squire
1996-10-23  0:00       ` Robert Dewar
1996-10-29  0:00         ` m193884
1996-10-29  0:00           ` Robert Dewar
  -- strict thread matches above, loose matches on Subject: below --
2014-04-10 10:41 AdaMagica
2014-04-10 14:43 ` Dmitry A. Kazakov
2014-04-10 15:15 ` Adam Beneschan
2014-04-10 17:36   ` Adam Beneschan
2014-04-10 22:49   ` Randy Brukardt
2014-04-10 23:16     ` Adam Beneschan
2014-04-10 18:44 ` AdaMagica
2014-04-10 19:07 ` sbelmont700
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox