Asynchronous Transfer of Control

Asynchronous Transfer of Control

[James Squire]

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"

Re: Asynchronous Transfer of Control

[Robert Dewar]

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.

Re: Asynchronous Transfer of Control

[Tucker Taft]

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

Re: Asynchronous Transfer of Control

[Robert A Duff]

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

Re: Asynchronous Transfer of Control

[Robert A Duff]

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

Re: Asynchronous Transfer of Control

[Ken Cowan]

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

Re: Asynchronous Transfer of Control

[Robert Dewar]

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.

Re: Asynchronous Transfer of Control

[Pascal Ledru]

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.

Re: Asynchronous Transfer of Control

[Robert Dewar]

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.

Re: Asynchronous Transfer of Control

[Larry Kilgallen]

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

Re: Asynchronous Transfer of Control

[Philip Brashear]

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

Re: Asynchronous Transfer of Control

[Dale Stanbrough]

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

Re: Asynchronous Transfer of Control

[Jon S Anthony]

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

Re: Asynchronous Transfer of Control

[Norman H. Cohen]

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

Re: Asynchronous Transfer of Control

[James Squire]

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"

Re: Asynchronous Transfer of Control

[Robert Dewar]

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

Re: Asynchronous Transfer of Control

[Robert Dewar]

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.

Re: Asynchronous Transfer of Control

[James Squire]

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"

Re: Asynchronous Transfer of Control

[Robert Dewar]

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.

Re: Asynchronous Transfer of Control

[Robert Dewar]

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.

Re: Asynchronous Transfer of Control

[m193884]

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!]

Asynchronous Transfer of Control

[AdaMagica]

This piece of code is very similar to RM 9.7.4(10-13).
It seems that GNT GPL 2013 on Windows does ot work correctly.

with Ada.Text_IO;
use  Ada.Text_IO;
with Ada.Calendar;
use  Ada.Calendar;

procedure Run_It is

  Line: String (1 .. 10);
  Last: Natural;
  Now : constant Time := Clock;

begin

  select
    delay 10.0;
    Put_Line ("aborted   " & Integer'Image (last) & Duration'Image (Clock - Now));
  then abort
    Put (" > ");
    Get_Line (Line, Last);
    Put_Line ("terminated" & Integer'Image (last) & Duration'Image (Clock - Now));
  end select;

end Run_It;

This is the result if I only press <return> after the delay has expired:
C:\...\Ada-Kode\run_it
 > 
terminated 0 26.688941821
aborted    0 26.689382659
[2014-04-10 12:24:42] process terminated successfully (elapsed time: 26.92s)

I.e. the abortable_part is not aborted.

Am I missing something? Or is this expected behaviour on Windows?

Re: Asynchronous Transfer of Control

[Dmitry A. Kazakov]

On Thu, 10 Apr 2014 03:41:15 -0700 (PDT), AdaMagica wrote:

> This piece of code is very similar to RM 9.7.4(10-13).
> It seems that GNT GPL 2013 on Windows does ot work correctly.

[...]

> I.e. the abortable_part is not aborted.
> 
> Am I missing something? Or is this expected behaviour on Windows?

Yes. Last time I checked it, GNAT's implementation of input from the
keyboard was not abortable under Windows.

Since ARM does not require it to work, AST is pretty much useless in most
(if not all) cases.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Asynchronous Transfer of Control

[Adam Beneschan]

On Thursday, April 10, 2014 3:41:15 AM UTC-7, AdaMagica wrote:
> This piece of code is very similar to RM 9.7.4(10-13).
> 
> It seems that GNT GPL 2013 on Windows does ot work correctly.
> 
> with Ada.Text_IO;
> use  Ada.Text_IO;
> with Ada.Calendar;
> use  Ada.Calendar;
> 
> procedure Run_It is
> 
>   Line: String (1 .. 10);
>   Last: Natural;
>   Now : constant Time := Clock;
> begin
>   select
>     delay 10.0;
>     Put_Line ("aborted   " & Integer'Image (last) & Duration'Image (Clock - Now));
>   then abort
>     Put (" > ");
>     Get_Line (Line, Last); 
>     Put_Line ("terminated" & Integer'Image (last) & Duration'Image (Clock - Now));
>   end select;
> end Run_It;
> 
> This is the result if I only press <return> after the delay has expired:
> 
> C:\...\Ada-Kode\run_it
> 
> terminated 0 26.688941821
> aborted    0 26.689382659
> 
> [2014-04-10 12:24:42] process terminated successfully (elapsed time: 26.92s)
> 
> I.e. the abortable_part is not aborted.
> 
> Am I missing something? Or is this expected behaviour on Windows?

The RM says that when the abortable_part is aborted, it doesn't actually have to stop executing until the next abort completion point.  The abort completion points are defined in 9.8(16-19).  The abortable_part *could* be terminated at other points (as long as they're not inside abort-deferred operations, see 9.8(6-11)), but it's up to the implementation.

I/O operations like Get_Line aren't abort completion points.  It seems reasonable that an implementation *should* provide for an I/O operation to be aborted if it could be forced to wait (e.g. input from the console, waiting for a socket connect, etc.).  But the RM doesn't require it.
  
Based on that, I think the examples in 9.7.4(10-13) are flawed.  While those kinds of examples may be the intended use of the asynchronous_select, they don't necessarily work, and the RM should probably make it clear that the effect is implementation-dependent.  In particular, the comment in the first example, "-- This will be abandoned upon terminal interrupt", appears to be making an assertion that is not necessarily true.  I'm planning on sending something to Ada-Comment about this.  (Don't know why I didn't notice this before.)  In the second example, we don't know whether Horribly_Complicated_Recursive_Function contains any abort completion points or not.  If it's a mathematical calculation, chances are that it doesn't; however, adding "delay 0.0;" statements at key places in the calculation would add abort compeltion points, and hopefully this statement would be implemented in a way so that it isn't a severe drag on efficiency.  (There's also Ada.Dispatching.Yield, which the RM says is a "task dispatching point", but it's not clear to me whether all task dispatching points are also abort completion points--seems like they should be, but I'd have to check the RM further.)

My understanding is that Windows makes it more difficult than, say, Unix/Linux to forcibly interrupt a thread, without that thread's cooperation.  That is, if I recall correctly, the thread to be interrupted has to use different versions of I/O API calls, and/or special API routines, that enable the operation to be interrupted.  I think that system designers have come to believe that allowing threads to be interrupted at any arbitrary point causes problems.  As I mentioned above, it may be a reasonable expectation that a keyboard input subprogram should allow for thread interruption, but others may have different opinions; anyway, it's not a requirement and GNAT apparently doesn't do it.

                                -- Adam 

Re: Asynchronous Transfer of Control

[Adam Beneschan]

On Thursday, April 10, 2014 8:15:53 AM UTC-7, I wrote:

> I/O operations like Get_Line aren't abort completion points.  It seems reasonable that an implementation *should* provide for an I/O operation to be aborted if it could be forced to wait (e.g. input from the console, waiting for a socket connect, etc.).  But the RM doesn't require it.

One thing I didn't notice is that 9.8(15) says:

"If the execution of a construct is aborted at a time when the execution is blocked, other than for an entry call, at a point that is outside the execution of an abort-deferred operation, then the execution of the construct completes immediately."

I'm still not convinced that applies here.  In an informal sense, a task that is waiting for the user to press a key could be said to be "blocked".  However, 9(10) discusses the different states a task goes through: "A task is initially inactive; upon activation, and prior to its termination it is either blocked (as part of some task interaction) or ready to run."  A task that is stopped because it's waiting for user input is not stopped "as part of some task interaction", so I don't think it's formally "blocked".

                           -- Adam

Re: Asynchronous Transfer of Control

[AdaMagica]

Thanks for your answers, Dmitry and Adam. I'll check again the corresponding paragraphs in the RM. (As always in these corner cases, the RM isn't an easy read.)

Christoph

Re: Asynchronous Transfer of Control

[sbelmont700]

On Thursday, April 10, 2014 6:41:15 AM UTC-4, AdaMagica wrote:
> It seems that GNT GPL 2013 on Windows does ot work correctly.

FWIT, GNAT does have the "Polling" pragma that is required on Windows to enable ATC.  However, even with that, as others have alluded to, ATC never really works quite right anyway.

-sb

Re: Asynchronous Transfer of Control

[Randy Brukardt]

"Adam Beneschan" <adambeneschan@gmail.com> wrote in message 
news:b00eabf3-5933-4c43-a75f-7137cd3fb95d@googlegroups.com...
...
>If it's a mathematical calculation, chances are that it doesn't; however, 
>adding
>"delay 0.0;" statements at key places in the calculation would add abort
>compeltion points, and hopefully this statement would be implemented in a 
>way
>so that it isn't a severe drag on efficiency.

It shouldn't be, but our experience with Claw was that not all implementers 
got the memo. (At least not until we submitted Claw bug reports to them.)

>(There's also Ada.Dispatching.Yield, which the RM says is a "task 
>dispatching
>point", but it's not clear to me whether all task dispatching points are 
>also
>abort completion points--seems like they should be, but I'd have to check 
>the
>RM further.)

I don't think they are, but it doesn't matter. Annex D requires immediate 
abort, so if you have Ada.Dispatching.Yield, you also have made everything 
essentially an abort completion point.

I'm not sure why abort completion points and task dispatching points are 
different in the RM; I'm pretty sure our implementation treats them as the 
same thing. Maybe that's also because of Annex D - task dispatching point is 
defined there and that's too late for the formal semantics of abort.

                                  Randy.

Re: Asynchronous Transfer of Control

[Adam Beneschan]

On Thursday, April 10, 2014 3:49:31 PM UTC-7, Randy Brukardt wrote:

> I don't think they are, but it doesn't matter. Annex D requires immediate 
> abort, so if you have Ada.Dispatching.Yield, you also have made everything 
> essentially an abort completion point.

Ah, I had forgotten about D.6.

                              -- Adam