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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5a05d88755a62a0e X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Asynchronous Transfer of Control Date: 1996/10/19 Message-ID: X-Deja-AN: 190578798 references: <32656457.1A76@csehp1.mdc.com> organization: New York University newsgroups: comp.lang.ada Date: 1996-10-19T00:00:00+00:00 List-Id: 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.