(j3.2006) (SC22WG5.3670) [ukfortran] N1755: Request for new features from MPI Forum

[Aleksandar Donev]

Nick,

> 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 
either...

Best,
Aleks

-- 
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
Web: http://cherrypit.princeton.edu/donev