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

[N.M. Maclaren]

On Nov 13 2008, Aleksandar Donev wrote:
>
>This argument is not progressing too much, so better to end soon. But:

Unfortunately, it needs resolving.  Whether that will be possible in Tokyo
or not, I don't know.  But I agree that this will have to stop :-)

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

I can't find any such proposal in that paper.  Because it is a change of
specification, adding an extra constraint, it needs to be in normative text.
I agree that you say such a constraint is needed - and I agree with you.
But there is currently no such constraint.

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

I am.  I attach a program that shows the problem.  Please note that this
one was debated to death in the early 1970s (yes, in the context of Fortran
66), and the people who claimed that Fortran mandated call-by-reference
were roundly defeated.  Fortran 90 introduced constructs that REQUIRE some
other mechanism (Iliffe vectors, Jensen's device, call by value/return or
whatever).  And both are well established in compilers and applications, in
a way that ASYNCHRONOUS and VOLATILE aren't.

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

It is currently almost useless, as my evidence shows.  In order to get it
right, you have to implement asynchronous I/O synchronously (but can do
it in either the data transfer or the WAIT).  That is what Intel 10.1 seems
to do.

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

Even if that is inconsistent with its stated intent and the rest of the
standard?  Oh, come now!  ISO SC22 rules allow for incompatible changes
where they fix clear defects, and I assume that ANSI X3 is similar.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Asynchronugh
Type: application/octet-stream
Size: 1704 bytes
Desc: Asynchronugh
Url : http://j3-fortran.org/pipermail/j3/attachments/20081113/8aa70420/attachment.obj