* Asynchronous Transfer of Control @ 1996-10-16 0:00 James Squire 1996-10-16 0:00 ` Robert Dewar 1996-10-17 0:00 ` Tucker Taft 0 siblings, 2 replies; 23+ messages in thread From: James Squire @ 1996-10-16 0:00 UTC (permalink / raw) The Ada 95 Rationale on page II-27 shows a short example of ATC that looks something like this: select delay 1.0; Text_IO.Put_Line ("Calculation could not be completed"); then abort Invert_Huge_Matrix (X); end select; I tried this, filling in nested for loops for the Invert_Huge_Matrix statement, and then I added a Text_IO.Put_Line at the end of the abortable part. I then ran this in the debugger and rigged it so that the delay would kick in first. BOTH my Put_Lines were executed, not to mention that the for loops were STILL completed. I reported it to the compiler vendor, and they pointed out to me from the AARM (9.8) that I didn't have an abort completion point in my abortable part. I looked at the list of things that qualify, and sure enough I don't. Unless I am barking up the wrong tree or something, I really don't understand this limitation. Is this yet another example of an invalid code sample in the Rationale? -- James Squire mailto:m193884@csehp1.mdc.com MDA Avionics Tools & Processes McDonnell Douglas Aerospace http://www.mdc.com/ Opinions expressed here are my own and NOT my company's "He must never know what happened. If he should find out, he must be killed. Do you understand, Delenn?" -- Grey Council #1 (re: Sinclair), "And the Sky Full of Stars" ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 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-17 0:00 ` Tucker Taft 1 sibling, 1 reply; 23+ messages in thread From: Robert Dewar @ 1996-10-16 0:00 UTC (permalink / raw) iJames asks "I reported it to the compiler vendor, and they pointed out to me from the AARM (9.8) that I didn't have an abort completion point in my abortable part. I looked at the list of things that qualify, and sure enough I don't. Unless I am barking up the wrong tree or something, I really don't understand this limitation. Is this yet another example of an invalid code sample in the Rationale?" The rationale simply assumes you have immediate abort, if not this code obviously will not work. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 1996-10-16 0:00 ` Robert Dewar @ 1996-10-23 0:00 ` James Squire 1996-10-23 0:00 ` Robert Dewar 0 siblings, 1 reply; 23+ messages in thread From: James Squire @ 1996-10-23 0:00 UTC (permalink / raw) Robert Dewar wrote: > > iJames asks > > "I reported it to the compiler vendor, and they pointed out to me from the > AARM (9.8) that I didn't have an abort completion point in my abortable > part. I looked at the list of things that qualify, and sure enough I > don't. > > Unless I am barking up the wrong tree or something, I really don't > understand this limitation. Is this yet another example of an invalid > code sample in the Rationale?" > > The rationale simply assumes you have immediate abort, if not this code > obviously will not work. Eh???? What do you mean by immediate abort and what do you mean by "having" it? I'm confused. -- James Squire mailto:m193884@csehp1.mdc.com MDA Avionics Tools & Processes McDonnell Douglas Aerospace http://www.mdc.com/ Opinions expressed here are my own and NOT my company's "Strange. I wonder why he appeared just to you [Londo], Draal and the Commander." 'Perhaps because we are most familiar with the third principle of sentient life." -- Delenn and Draal, "A Voice in the Wilderness II" ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 1996-10-23 0:00 ` James Squire @ 1996-10-23 0:00 ` Robert Dewar 0 siblings, 0 replies; 23+ messages in thread From: Robert Dewar @ 1996-10-23 0:00 UTC (permalink / raw) James Squire asks "Eh???? What do you mean by immediate abort and what do you mean by "having" it? I'm confused." Simple enough, an immediate abort is one that happens when the abort happens. A non-immediate abort waits for a while, as long as, but not longer than, the time till the next abort completion point is reached. If you want an immediate abort, be sure your compiler implements the real time annex, or at least this part of it t ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 1996-10-16 0:00 Asynchronous Transfer of Control James Squire 1996-10-16 0:00 ` Robert Dewar @ 1996-10-17 0:00 ` Tucker Taft 1996-10-17 0:00 ` Robert A Duff 1 sibling, 1 reply; 23+ messages in thread From: Tucker Taft @ 1996-10-17 0:00 UTC (permalink / raw) James Squire (m193884@csehp1.mdc.com) wrote: : The Ada 95 Rationale on page II-27 shows a short example of ATC that : looks something like this: : select : delay 1.0; : Text_IO.Put_Line ("Calculation could not be completed"); : then abort : Invert_Huge_Matrix (X); : end select; : I tried this, filling in nested for loops for the Invert_Huge_Matrix : statement, and then I added a Text_IO.Put_Line at the end of the : abortable part. : I then ran this in the debugger and rigged it so that the delay would : kick in first. BOTH my Put_Lines were executed, not to mention that the : for loops were STILL completed. : I reported it to the compiler vendor, and they pointed out to me from the : AARM (9.8) that I didn't have an abort completion point in my abortable : part. I looked at the list of things that qualify, and sure enough I : don't. Abort completion points are only important if the compiler does not support preemptive abort (D.6). Ask your vendor whether they support preemptive abort (it is required if they support the Real-Time annex). If they claim to support it, then you have found a bug. If not, then you may have to find a new compiler, or encourage your vendor to implement preemptive abort, or insert periodic abort completion points (which admittedly defeats the main purpose for ATC). In general, ATC is built on the same mechanism as abort. It was controversial during the Ada 9X design because of this, but ultimately that is also why it was accepted -- it doesn't really introduce problems that are significantly harder than handling abort (especially now that abort has to deal with arbitrary finalization). The down side of this connection is that if abort is not supported preemptively, then ATC is probably also not preemptive (sort of a "synchronous" Asynchronous Transfer of Control ;-). : Unless I am barking up the wrong tree or something, I really don't : understand this limitation. Is this yet another example of an invalid : code sample in the Rationale? The Rationale was presuming support for preemptive abort. The abort statement, and the asynchronous select, are admittedly not too useful if the vendor doesn't support preemptive abort. : James Squire mailto:m193884@csehp1.mdc.com : MDA Avionics Tools & Processes : McDonnell Douglas Aerospace http://www.mdc.com/ : Opinions expressed here are my own and NOT my company's : "He must never know what happened. If he should find out, he must : be killed. Do you understand, Delenn?" : -- Grey Council #1 (re: Sinclair), "And the Sky Full of Stars" -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Cambridge, MA USA ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 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 ` (3 more replies) 0 siblings, 4 replies; 23+ messages in thread From: Robert A Duff @ 1996-10-17 0:00 UTC (permalink / raw) In article <DzF1Fo.CJs.0.-s@inmet.camb.inmet.com>, Tucker Taft <stt@houdini.camb.inmet.com> wrote: >Abort completion points are only important if the compiler does not >support preemptive abort (D.6). Ask your vendor whether they support >preemptive abort (it is required if they support the Real-Time annex). On Windows 95, the only way I can see to implement preemptive abort/ATC is for the compiler to insert polling code all over the program (maybe at every call, and at every backward jump?). If true, this is horrible -- operating systems of decades ago had proper support for this sort of thing, but the latest and greatest doesn't. Does any compiler do this? Is there any better way to implement it on windows 95? There's some sort of kill-thread operation, but that would skip finalization. I think the situation is the same for OS/2. What about windows/NT? - Bob ^ permalink raw reply [flat|nested] 23+ messages in thread
* Latest /= Greatest (was: Asynchronous Transfer of Control) 1996-10-17 0:00 ` Robert A Duff @ 1996-10-17 0:00 ` Larry Kilgallen 1996-10-22 0:00 ` Asynchronous Transfer of Control Dale Stanbrough 1996-10-18 0:00 ` Ken Cowan ` (2 subsequent siblings) 3 siblings, 1 reply; 23+ messages in thread From: Larry Kilgallen @ 1996-10-17 0:00 UTC (permalink / raw) In article <DzFAMr.6DG@world.std.com>, bobduff@world.std.com (Robert A Duff) writes: > On Windows 95, the only way I can see to implement preemptive abort/ATC > is for the compiler to insert polling code all over the program (maybe > at every call, and at every backward jump?). If true, this is horrible > -- operating systems of decades ago had proper support for this sort of > thing, but the latest and greatest doesn't. Um, I don't think most Ada folk universally subscribe to the theory that: <latest> = <greatest> There is no reason to suspect that the bulk of operating systems are getting better and better. Consider that they are being sold to an ever-widening circle of less-experienced consumers (including businesses). Larry Kilgallen ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 1996-10-17 0:00 ` Latest /= Greatest (was: Asynchronous Transfer of Control) Larry Kilgallen @ 1996-10-22 0:00 ` Dale Stanbrough 0 siblings, 0 replies; 23+ messages in thread From: Dale Stanbrough @ 1996-10-22 0:00 UTC (permalink / raw) Larry Kilgallen writes: "Um, I don't think most Ada folk universally subscribe to the theory that: <latest> = <greatest> " I suspect the rule that many people subscribe to is <greatest> = <latest> where '=' is a well known operator from another language :-). Dale ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 1996-10-17 0:00 ` Robert A Duff 1996-10-17 0:00 ` Latest /= Greatest (was: Asynchronous Transfer of Control) Larry Kilgallen @ 1996-10-18 0:00 ` Ken Cowan 1996-10-18 0:00 ` Robert A Duff ` (2 more replies) 1996-10-22 0:00 ` Jon S Anthony 1996-10-23 0:00 ` James Squire 3 siblings, 3 replies; 23+ messages in thread From: Ken Cowan @ 1996-10-18 0:00 UTC (permalink / raw) In article <DzFAMr.6DG@world.std.com>, bobduff@world.std.com (Robert A Duff) wrote: >On Windows 95, the only way I can see to implement preemptive abort/ATC >is for the compiler to insert polling code all over the program (maybe >at every call, and at every backward jump?). If true, this is horrible >-- operating systems of decades ago had proper support for this sort of >thing, but the latest and greatest doesn't. Does any compiler do this? >Is there any better way to implement it on windows 95? There's some >sort of kill-thread operation, but that would skip finalization. I >think the situation is the same for OS/2. What about windows/NT? > >- Bob 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. KC --------------------------------------------------------- Ken Cowan Thomson Software Products cowan@east.thomsoft.com 200 Wheeler Rd. phone: (617) 221-7323 Burlington, MA 01803 fax: (617) 220-6882 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 1996-10-18 0:00 ` Ken Cowan @ 1996-10-18 0:00 ` Robert A Duff 1996-10-19 0:00 ` Robert Dewar 1996-10-21 0:00 ` Pascal Ledru 2 siblings, 0 replies; 23+ messages in thread From: Robert A Duff @ 1996-10-18 0:00 UTC (permalink / raw) In article <DzH5n3.2rE@thomsoft.com>, Ken Cowan <cowan@east.alsys.com> wrote: >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. OK, that proves it can be done, but I'm still curious as to how it works. I don't remember reading about any "resume at some particular place" primitive in the win 95 documentation I've read. Which system calls, exactly, are being used? Or does the Ada RTS poke the saved PC value of the thread, so it will resume at a different spot? If so, is there a documented way of getting at the saved PC (and other thread registers). (By PC I mean EIP, of course, on 80x86.) - Bob ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 1996-10-18 0:00 ` Ken Cowan 1996-10-18 0:00 ` Robert A Duff @ 1996-10-19 0:00 ` Robert Dewar 1996-10-21 0:00 ` Philip Brashear 1996-10-22 0:00 ` Norman H. Cohen 1996-10-21 0:00 ` Pascal Ledru 2 siblings, 2 replies; 23+ messages in thread From: Robert Dewar @ 1996-10-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 1996-10-19 0:00 ` Robert Dewar @ 1996-10-21 0:00 ` Philip Brashear 1996-10-21 0:00 ` Validation vs. Certification (was: Asynchronous Transfer of Control) Larry Kilgallen 1996-10-21 0:00 ` Asynchronous Transfer of Control Robert Dewar 1996-10-22 0:00 ` Norman H. Cohen 1 sibling, 2 replies; 23+ messages in thread From: Philip Brashear @ 1996-10-21 0:00 UTC (permalink / raw) In article <dewar.845732555@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: >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. Actually, ObjectAda for Windows did pass all the Annex D tests (except the one Robert referred to), but we can't quite characterize that as being "validated for Annex D". Under ACVC 2.0, implementations are validated (or not) without regard to the Specialized Needs Annexes. If an implementation chooses to try one or more of the SA Annexes, the results are reported in an attachment to the certificate. There is no certification for an SA Annex. (The UNIX versions of ObjectAda, validated under ACVC 2.0.1, did not attempt any of the Annex D tests.) Yes, this is somewhat picky, but that's what validation and certification are all about -- being picky. Phil Brashear CTA INCORPORATED ^ permalink raw reply [flat|nested] 23+ messages in thread
* Validation vs. Certification (was: Asynchronous Transfer of Control) 1996-10-21 0:00 ` Philip Brashear @ 1996-10-21 0:00 ` Larry Kilgallen 1996-10-21 0:00 ` Asynchronous Transfer of Control Robert Dewar 1 sibling, 0 replies; 23+ messages in thread From: Larry Kilgallen @ 1996-10-21 0:00 UTC (permalink / raw) In article <54fnb1$5m7@ns1.sw-eng.falls-church.va.us>, brashear@ns1.sw-eng.falls-church.va.us (Philip Brashear) writes: > Actually, ObjectAda for Windows did pass all the Annex D tests (except the one > Robert referred to), but we can't quite characterize that as being "validated > for Annex D". Under ACVC 2.0, implementations are validated (or not) without > regard to the Specialized Needs Annexes. If an implementation chooses to try > one or more of the SA Annexes, the results are reported in an attachment to the > certificate. There is no certification for an SA Annex. (The UNIX versions > of ObjectAda, validated under ACVC 2.0.1, did not attempt any of the Annex D > tests.) > > Yes, this is somewhat picky, but that's what validation and certification are > all about -- being picky. I am familiar with such rigorous use of terminology in the US Government program for rating the security features of operating systems (C2, B1, etc.). They use the terms evaluation, certification, etc. in an equally rigorous fashion but with a different set of meanings than those described for Ada. Perhaps some Ada folk in the US government could go around giving lectures on re-use in general rather than just in software. Larry Kilgallen ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 1996-10-21 0:00 ` Philip Brashear 1996-10-21 0:00 ` Validation vs. Certification (was: Asynchronous Transfer of Control) Larry Kilgallen @ 1996-10-21 0:00 ` Robert Dewar 1996-10-21 0:00 ` Larry Kilgallen 1 sibling, 1 reply; 23+ messages in thread From: Robert Dewar @ 1996-10-21 0:00 UTC (permalink / raw) Phil Brashear said "Actually, ObjectAda for Windows did pass all the Annex D tests (except the one Robert referred to), but we can't quite characterize that as being "validated for Annex D". Under ACVC 2.0, implementations are validated (or not) without regard to the Specialized Needs Annexes. If an implementation chooses to try one or more of the SA Annexes, the results are reported in an attachment to the certificate. There is no certification for an SA Annex. (The UNIX versions of ObjectAda, validated under ACVC 2.0.1, did not attempt any of the Annex D tests.) Yes, this is somewhat picky, but that's what validation and certification are all about -- being picky." Well being picky is OK, but let's not obfuscate in the process! There is something very important about TSP being able to say that they passed all applicable tests in Annex D. It is possible that this will be all we ever mean by "validated for annex D", as far as I know we still did not make a decision as to whether the 2.1 certificates will have gold stars on them for SN annexes passes. So the critical question is, does a particular implementation pass all the applicable tests for a given SN annex. The VSR will answer this question. In the extended discussion about the priority test (as I recall Phil was not involved in this discussion, but I may recall wrong), the critical question was whether the test in question was failed or properly judged as inapplicable. This is a critical decision. If it is judged to be failed, then TSP cannot say that their validation includes 100% of the required tests in the SN annex, if it is judged inapplicable, then TSP can indeed say that their validation includes validation of the whole of annex D. In fact, the ruling of the AVO, after much discussion, was precisely that this test (the one requiring 31 priority levels) could indeed be ruled inapplicable for TSP, so they can claim quite rightly that their validation includes validation for the real time annex as well as the core. During the entire validation process, we have recognized the critical importance of this status (of a paritcular compiler passing all the validation tests for a given SN annex). There is still some dicussion of whether the valiation certificate will call out on the front of the certificate which SN annexes are thus validated, but this is irrelevant to the critical issue, fully and clearly documented in the VSR, of which SN annexes are covered fully. So Phil may be technically right about the phrase "validated *for* the SN annex", but this does not detract from the critical status of compilers that do indeed validate a given SN annex entirely. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 1996-10-21 0:00 ` Asynchronous Transfer of Control Robert Dewar @ 1996-10-21 0:00 ` Larry Kilgallen 1996-10-26 0:00 ` Robert Dewar 0 siblings, 1 reply; 23+ messages in thread From: Larry Kilgallen @ 1996-10-21 0:00 UTC (permalink / raw) In article <dewar.845917922@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes: > In fact, the ruling of the AVO, after much discussion, was precisely that > this test (the one requiring 31 priority levels) could indeed be ruled > inapplicable for TSP, so they can claim quite rightly that their validation > includes validation for the real time annex as well as the core. If the decision had been otherwise, it seems to me the validation process would have become a matter of rating operating systems rather than compilers. That does not serve the needs of those who have already chosen an operating system and now must choose a compiler for it. There are few ways to discourage a would be Ada project so effective as saying "Well, _real_ Ada cannot be done on the operating system you have chosen." CPM and RSTS advocates should get that brush-off, but not Windows NT fans. The world cares a lot more about Windows NT than Ada (this month). Larry Kilgallen ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 1996-10-21 0:00 ` Larry Kilgallen @ 1996-10-26 0:00 ` Robert Dewar 0 siblings, 0 replies; 23+ messages in thread From: Robert Dewar @ 1996-10-26 0:00 UTC (permalink / raw) Larry says "If the decision had been otherwise, it seems to me the validation process would have become a matter of rating operating systems rather than compilers. That does not serve the needs of those who have already chosen an operating system and now must choose a compiler for it. There are few ways to discourage a would be Ada project so effective as saying "Well, _real_ Ada cannot be done on the operating system you have chosen." CPM and RSTS advocates should get that brush-off, but not Windows NT fans. The world cares a lot more about Windows NT than Ada (this month)." Yes, indeed, however, I hope everyone realizes that there is a technical issue here. In particular, rate monotonic scheduling is very severely rstricted as a usable technique with only seven levels of priority, so as always, we are in buyer beware territory. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 1996-10-19 0:00 ` Robert Dewar 1996-10-21 0:00 ` Philip Brashear @ 1996-10-22 0:00 ` Norman H. Cohen 1 sibling, 0 replies; 23+ messages in thread From: Norman H. Cohen @ 1996-10-22 0:00 UTC (permalink / raw) Robert Dewar wrote: > 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. What, NEVER? Well, hardly ever. But ATC is safe as long as the abortable part implements a transaction, i.e., as long as it appears, at the end of the select statement, as having either taken place in its entirety or not having been started. In other words, ATC is safe as long as the abortable part has no side effects in cases where it is aborted. How often is ATC useful, given this restriction? Well, as I said, hardly ever. But here are some examples: o The user in an interactive application clicks a "Stop" button, indicating that some work is taking longer than he anticipated, and he would like to abandon it, discarding everything accomplished until that point. o A piece of periodic processing in a cyclic executive overruns its time slot and is abandoned, producing no result for that period. o In a parallel search, the first task to find the target of the search reports its victory by calling a protected procedure that opens an entry, triggering the abortion of the master of all the search tasks. o The last action in the abortable part is an atomic update of a pointer, to point to some data structure that is not accessible outside the abortable part until this update. The bulk of the work of the abortable part is to update the data structure pointed to, but none of this has any effect on the rest of the program if the abortable part never gets to the atomic update of the pointer. It is also safe if the work of the abortable part consists of a series of transactions, each of which is NATURALLY expressed as a protected operation. -- Norman H. Cohen mailto:ncohen@watson.ibm.com http://www.research.ibm.com/people/n/ncohen ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 1996-10-18 0:00 ` Ken Cowan 1996-10-18 0:00 ` Robert A Duff 1996-10-19 0:00 ` Robert Dewar @ 1996-10-21 0:00 ` Pascal Ledru 2 siblings, 0 replies; 23+ messages in thread From: Pascal Ledru @ 1996-10-21 0:00 UTC (permalink / raw) For more implementation details on ATC, look at the paper: "Ada 9X Asynchronous Transfer of Control: Application And Implementation" From Giering and Baker. (ACM SIGPLAN Workshop on Language, Compiler, and Tool Support for Real-Time Systems, June 1994) I believe they were the original authors of GNARL. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 1996-10-17 0:00 ` Robert A Duff 1996-10-17 0:00 ` Latest /= Greatest (was: Asynchronous Transfer of Control) Larry Kilgallen 1996-10-18 0:00 ` Ken Cowan @ 1996-10-22 0:00 ` Jon S Anthony 1996-10-23 0:00 ` James Squire 3 siblings, 0 replies; 23+ messages in thread From: Jon S Anthony @ 1996-10-22 0:00 UTC (permalink / raw) In article <1996Oct21.180838.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes: > In article <dewar.845917922@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes: > > > In fact, the ruling of the AVO, after much discussion, was precisely that > > this test (the one requiring 31 priority levels) could indeed be ruled > > inapplicable for TSP, so they can claim quite rightly that their validation > > includes validation for the real time annex as well as the core. > > If the decision had been otherwise, it seems to me the validation > process would have become a matter of rating operating systems > rather than compilers. That does not serve the needs of those > who have already chosen an operating system and now must choose > a compiler for it. There are few ways to discourage a would be > Ada project so effective as saying "Well, _real_ Ada cannot be > done on the operating system you have chosen." CPM and RSTS > advocates should get that brush-off, but not Windows NT fans. > The world cares a lot more about Windows NT than Ada (this month). Absolutely. Good thing this insanity was nipped in the bud. I think Robert put it best when he said that if this had not been approved and no compiler could have validated D on Win/NT, then the response would have been, "Gee, I thought I could use real Ada on NT for real-time - guess not. Well, I'm not changing from NT (that's fer sure), so it looks like I just won't be using Ada". Given the "not validated => use C++" insanity/stupidity/excuse, this seems pretty obvious... /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 1996-10-17 0:00 ` Robert A Duff ` (2 preceding siblings ...) 1996-10-22 0:00 ` Jon S Anthony @ 1996-10-23 0:00 ` James Squire 1996-10-23 0:00 ` Robert Dewar 3 siblings, 1 reply; 23+ messages in thread From: James Squire @ 1996-10-23 0:00 UTC (permalink / raw) In article <DzF1Fo.CJs.0.-s@inmet.camb.inmet.com>, Tucker Taft <stt@houdini.camb.inmet.com> wrote: >Abort completion points are only important if the compiler does not >support preemptive abort (D.6). Ask your vendor whether they support >preemptive abort (it is required if they support the Real-Time annex). They have not released their implementation of Annex D yet. I will forward this on to them. I think it would have been clearer to place your sentence into the LRM to let people know that abort completion points are only important if the compiler does not support preemptive abort. -- James Squire mailto:m193884@csehp1.mdc.com MDA Avionics Tools & Processes McDonnell Douglas Aerospace http://www.mdc.com/ Opinions expressed here are my own and NOT my company's "Strange. I wonder why he appeared just to you [Londo], Draal and the Commander." 'Perhaps because we are most familiar with the third principle of sentient life." -- Delenn and Londo, "A Voice in the Wilderness II" ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 1996-10-23 0:00 ` James Squire @ 1996-10-23 0:00 ` Robert Dewar 1996-10-29 0:00 ` m193884 0 siblings, 1 reply; 23+ messages in thread From: Robert Dewar @ 1996-10-23 0:00 UTC (permalink / raw) James Squire says "They have not released their implementation of Annex D yet. I will forward this on to them. I think it would have been clearer to place your sentence into the LRM to let people know that abort completion points are only important if the compiler does not support preemptive abort." The RM is quite clear, in 9.8, we have 24 (40) Additional requirements associated with abort are given in D.6, ``Preemptive Abort''. And in the referenced section D.6, we find D.6 Preemptive Abort 1 This clause specifies requirements on the immediacy with which an aborted construct is completed. I don't know where else you would look int the RM for semantics of abort other than these two sections. Note that it is NOT the case that abort completion points are only important if the compiler does not support preemptive abort, I don't know where you got this idea. The rule is that an abort CANNOT happen later than the point of an abort completion point, and this absolute rule applies regardless of the requirements in D.5(2-12) which do NOT contains this specific requirement. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 1996-10-23 0:00 ` Robert Dewar @ 1996-10-29 0:00 ` m193884 1996-10-29 0:00 ` Robert Dewar 0 siblings, 1 reply; 23+ messages in thread From: m193884 @ 1996-10-29 0:00 UTC (permalink / raw) To: Robert Dewar I just noticed the answer to one of Robert's questions, and I thought I would point out a possible confusion. In article <32656457.1A76@csehp1.mdc.com> <DzF1Fo.CJs.0.-s@inmet.camb.inmet.com> <DzFAMr.6DG@world.std.com> <326E3BD9.62CB@csehp1.mdc.com> <dewar.846112325@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > other than these two sections. Note that it is NOT the case that ^^^ > abort completion points are only important if the compiler does not ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > support preemptive abort, I don't know where you got this idea. The ^^^^^^^^^^^^^^^^^^^^^^^^ > rule is that an abort CANNOT happen later than the point of an > abort completion point, and this absolute rule applies regardless > of the requirements in D.5(2-12) which do NOT contains this specific > requirement. It was right there in my reply. Go take it up with Tucker Taft. One of you is confused or wrong. It ain't me. In article <DzF1Fo.CJs.0.-s@inmet.camb.inmet.com>, Tucker Taft <stt@houdini.camb.inmet.com> wrote: >Abort completion points are only important if the compiler does not ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >support preemptive abort (D.6). Ask your vendor whether they support ^^^^^^^^^^^^^^^^^^^^^^^^ >preemptive abort (it is required if they support the Real-Time annex). See what I mean? -- James Squire mailto:m193884@csehp1.mdc.com MDA Avionics Tools & Processes McDonnell Douglas Aerospace http://www.mdc.com/ Opinions expressed here are my own and NOT my company's "Take my advice and go back to the time you came from. The future isn't what it used to be." -- G'Kar, "The Long Dark" ----------------------------------------------------------------------- This article was posted to Usenet via the Posting Service at Deja News: http://www.dejanews.com/ [Search, Post, and Read Usenet News!] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Asynchronous Transfer of Control 1996-10-29 0:00 ` m193884 @ 1996-10-29 0:00 ` Robert Dewar 0 siblings, 0 replies; 23+ messages in thread From: Robert Dewar @ 1996-10-29 0:00 UTC (permalink / raw) James Squire worries about me noting that abort completion points are still important if annex D is implemented, when Tuck said they are not. In fact these statements are not inconsistent, even though they appear to be. What Tuck was saying is that if you are worried about the immediacy of abort, then the issue of abort completion points is not important, since it is annex D that describes the latency of aborts. What I was saying is that if you are concerned with the exact set of events that can occur, in terms of reasoning formally about state, then abort completion points are important. What an abort completion point promises is that if a task is aborted, then it is NEVER the case that a statement after this point is executed, even if the latency guaranteed in annex D would permit such an execution sequence. It is quite possible to construct a test where this reasoning makes a difference to the invariants of the program state after the abort has taken place. ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~1996-10-29 0:00 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 1996-10-21 0:00 ` Philip Brashear 1996-10-21 0:00 ` Validation vs. Certification (was: Asynchronous Transfer of Control) Larry Kilgallen 1996-10-21 0:00 ` Asynchronous Transfer of Control Robert Dewar 1996-10-21 0:00 ` Larry Kilgallen 1996-10-26 0:00 ` Robert Dewar 1996-10-22 0:00 ` 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox