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

[Aleksandar Donev]

HI Nick,

This argument is not progressing too much, so better to end soon. But:
> It is also totally foul to implement for ASYNCHRONOUS :-( Consider a 
> variable Wurzel with the ASYNCHRONOUS attribute that MAY have pending I/O 
> on it, and is passed as an argument to a procedure without ASYNCHRONOUS. As 
> I read the wording, that is permitted even if there IS pending I/O unless 
> that procedure actually references, defines, undefines or changes Wurzel.
That is not at all what I or the paper I mentioned (08-165) said. If the 
variable has pending I/O on it, then the dummy should have asynchronous 
as well. The processor needs to do nothing different, since it is as if 
the variable were not asynchronous, at that point in time. The issue of 
"may" versus "is" I am not sure of.

Without this, you make asynchronous useless, since you cannot even call 
an old library routine on that variable, even if there is no async I/O 
pending or happening. That would indeed be a BUG in the standard.

And at this point in the game, we cannot change our minds to require 
async/volatile to be matched between dummy and actual. All combinations 
are allowed in F2003, and must remain so. For MPI or some such library 
it sure is useful to require the matching if nothing else to force 
programmers to put it on the actual if they are calling non-blocking 
I/O. But that would at this point require a new attribute indeed.

Obviously, there are different mental/semantic models here of what ASYNC 
and VOLATILE really mean, when they are really necessary, and what 
guarantees/safeties the standard should provide. Perhaps the original 
designers had one of these models in mind, but I am not sure reading the 
text and as I mentioned asking J3/WG5 several times to explain it went 
silent. I asked what the note that 08-165 changes means and why it says 
what I consider obviously wrong things, and Bill at first defended it 
but then agreed that my suggested modification was in fact right. 
Anyway, we will go in circles until someone actually explains what the 
intention is here before we argue over edits.

Best,
Aleks