(j3.2006) Comment on Fortran WG5 ballot N1846

Van Snyder Van.Snyder
Wed Apr 20 16:33:17 EDT 2011


On Wed, 2011-04-20 at 12:48 -0700, Dan Nagle wrote:
> Hello,
> 
> On Apr 20, 2011, at 13:17 , Van Snyder wrote:
> > 
> > I don't anticipate that a processor will have a global "pending" flag
> > for every variable with the ASYNCHRONOUS attribute.
> 
> But the processor must keep a pending/done signal per transfer,
> otherwise inquire id= won't work.  So it can be checked.

Whether "the transfer" is still pending can be checked (where there is
access to the id=), but in

  asynchronous X
  external A, B
  call A ( X )
  call B
  print *, X
  end

the processor almost certainly doesn't know what "the transfer" (or,
indeed, any particular transfer) means with respect to X.

It probably can't know without substantial overhead (a globally
accessible data structure associated with X, and that could get marked
by any asynchronous transfer or wait operation anywhere in the program).
In the above example, since A is external with implicit interface, the
means of accessing that data structure can't be in a descriptor sent to
A, so it would have to be global, and accessible by, for example,
hashing the address of X.  I suspect no processor would go to that
trouble, since the overhead associated with it would almost certainly be
more costly than not doing it.

This almost certainly means that any processor that supports
asynchronous I/O simply has to respect the semantics specified for a
variable with the ASYNCHRONOUS attribute, and can't take advantage of
anything else concerning such a variable it it is accessible outside the
scoping unit where I/O statements concerning it occur.

> >> 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 point being, the compiler knows exactly what "worst-case"
> means when it knows that asynchronous applies only to its own
> f08 asynchronous i/o.

Not in the main program illustrated above, or indeed in any program unit
where a variable with the ASYNCHRONOUS attribute is or might be
accessible to an external procedure.  For example, if A above were a
module procedure, but the processor just made a wild-eyed guess that A
might invoke an external procedure and give it access to X, the same
argument holds, and anywhere further along the call chain by induction.

> (In the example I gave, the compiler knows that actual data transfers
> may happen only in write statements or in wait statements, and not elsewhere.)

In the example I gave, it doesn't, and can't.

> The difficulty is that "worst-case" means something different
> when it may also apply to an arbitrary asynchronous communications
> library.
> 
> (The difficulty of defining what is communications and what is
> other processing is icing on the cake merely.)

Yes.  And the ASYNCHRONOUS attribute says "subvert the optimizer, but
not as much as you would if I'd used the TARGET attribute."

In a scoping unit where a variable has the ASYNCHRONOUS attribute, and
the variable is accessible to an external procedure, the processor
doesn't and can't know the difference between asynchronous I/O and
asynchronous anything else.

The words I proposed (far simpler than John's proposal) would change the
program's responsibility, not the processor's.





More information about the J3 mailing list