(j3.2006) Comment on Fortran WG5 ballot N1846

[Van Snyder]

On Wed, 2011-04-20 at 08:14 -0700, Dan Nagle wrote:
> Hello,
> 
> On Apr 20, 2011, at 02:29 , Van Snyder wrote:
> 
> > This is all true, but is irrelevant to the fact that in the program
> > 
> > asynchronous X
> > external A, B
> > call A ( X )
> > call B
> > print *, X
> > end
> > 
> > the processor can't know if or how X is asynchronous.
> 
> The processor doesn't know where the asynchronous i/o happens,
> nor where the wait happens.  So what.  The processor does know
> the limits of what asynchronous means, provided asynchronous
> is restricted to f08 asynchronous i/o.
> 
> >  If it provides asynchronous I/O, it has to respect the ASYNCHRONOUS
> attribute, no matter whether or how the "asynchronous" happens in A.
> 
> Note the hypothesis:  "If it provides asynchronous I/O".
> 
> Knowing how asynchronous happens, including if it happens at all,
> is the point.  The processor can do the minimum is knows it needs to
> do if the asynchronous attribute applies only to f08 asynchronous i/o.
> 
> For example, a processor could generate two code paths for each basic
> optimization block, and use a run-time test of the pending/done
> indicator to select which block to execute, if asynchronous is
> restricted to its own f08 standard asynchronous i/o.  The processor
> can't do that if asynchronous is enlarged to include anything anyone
> considers to be asynchronous "communications".

I don't anticipate that a processor will have a global "pending" flag
for every variable with the ASYNCHRONOUS attribute.

> If the asynchronous attribute applies further, to arbitrary
> communications, the processor must make worst-case assumptions every
> time.

I anticipate processors will always make the worst-case assumptions
concerning asynchronous objects because doing anything else would almost
certainly be a net loss.

> >> The red herring is how many levels of call are involved.
>