(j3.2006) (SC22WG5.3678) [ukfortran] N1755: Request for new features from MPI Forum
Thu Nov 13 08:44:21 EST 2008
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.
More information about the J3