(j3.2006) (SC22WG5.3670) [ukfortran] N1755: Request for new features from MPI Forum
Wed Nov 12 22:23:36 EST 2008
> In Fortran, as in traditional languages, the purpose of constraints is so
> that the processor AND programmer can rely on certain guarantees. Such as,
> when debugging, I know that an INTENT(IN) variable cannot change unless I
> also have a much more serious error that trashes memory.
*Unless*, they also have the VOLATILE attribute! Two attributes together
mean something different. The contract should be as follows: If the
programmer knows that the value of the actual can change during the
execution of the program by means outside of the program (which, by the
way, are under the control and responsibility of the programmer, not
God!), then he/she is obliged to put the VOLATILE attribute on the dummy
so as to tell that to the compiler. The constraints ensure that no copy
in/out will be performed and thus those changes will be visible in the
routine. The INTENT(IN) attribute means that the value should not change
because of actions in the routine itself. In particular, external means
should not modify the value unless *both* the actual and the dummy are
VOLATILE. If it is intent OUT or INOUT or unspecified, then you can only
add VOLATILE to the dummy if the volatility only occurs while the
routine is executing but not once it finishes: the changes become
visible to the caller upon return.
> One of the reasons that the volatile concept in all of its incarnations is
> such a problem that it means that such constraints still bind the programmer
> but do not provide the guarantees any longer.
Correct, which is why those constraints are stupid and should not be
there. It is the programmer's responsibility to manage the interaction
with the non-Fortran processes, and to add the attribute when necessary.
At the same time, he/she should have the freedom to omit it when it is
not necessary, to permit optimizations. Adding silly constraints that
prevent nothing but restrict the "management" cannot be rationalized by
the types of explanations you and Bill have provided.
> Because ASYNCHRONOUS never allows the value to change from one defined
> value to another defined value without the programmer explicitly doing it.
VOLATILE simply means (in my book) that the value changes by means other
than Fortran, not by means out of the control of the programmer. If you
call an external I/O routine, like MPI, and it works asynchronously,
there is no difference with Fortran ASYNCHRONOUS I/O and what you need
to do is use the VOLATILE attribute instead. I am well-aware this is not
a good language design, but it is the only legal option within the
Fortran 2003 standard, and in fact, one of the intended uses of VOLATILE.
> Nothing. If that were what Fortran specified. But it isn't. I can't see
> much point in replacing one simple constraint by a much more complicated
> one, in order to provide a feature that few people will ever want to use!
Except that, the current constraints are not self-consistent, as you may
recognize. They don't actually ensure "safety", rather, just add
restrictions to work around.
BTW, I was not involved in J3 when VOLATILE/ASYNCHRONOUS were added
Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ LLNL
High Performance Computational Materials Science and Chemistry
E-mail: donev1 at llnl.gov
Phone: (925) 424-6816 Fax: (925) 423-0785
Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
More information about the J3