[MPI3 Fortran] MPI buffer arguments - void and call-by-reference

N.M. Maclaren nmm1 at cam.ac.uk
Mon Feb 16 15:30:42 CST 2009


On Feb 16 2009, Aleksandar Donev wrote:
>
>> Um.  While that is true, to a first approximation, it isn't really.  The
>> reason is that all three of those have subtly different constraints on
>> when a compiler must not use copy-in/copy-out and other optimisations. 
>
>While this is true, I am really not sure what your message was meant to 
>illustrate or clarify...it was confusing even to me (and I am at least 
>familiar with the subtleties).

Sorry!

>> The only one of those that ABSOLUTELY blocks copy-in/copy-out and the
>> more-or-less equivalent optimisations is VOLATILE.  ASYNCHRONOUS does
>> the least blocking, and is therefore the most efficient.
>
>As far as copy in/out is concerned, VOLATILE and ASYNCHRONOUS are 
>identical as far as the standard is concerned. Specifically, a situation 
>where copy in/out may be required to be performed is prohibited by 
>compile-time constraints. This is not quite identical to saying "though 
>shall not perform copy in/out", but the reason the compile-time 
>constraints are there is so as to ensure that the argument passing can 
>be done by pass-by-reference.

Everything you say is correct, except for the first sentence!  The
restrictions on ASYNCHRONOUS make a MAJOR difference.  Consider the
following common paradigm:

    REAL, ASYNCHRONOUS :: buffer(1000)
    CALL Remote_transfer_1(buffer, ...)
    CALL Manipulate(buffer)
    CALL Remote_transfer_2(buffer, ...)

Where the source of Manipulate is visible to the compiler, and it can
see that there are no external calls or Fortran asynchronous I/O
statements.  It can then optimise the call to Manipulate exactly as
if it had no attribute, because the pending state cannot change during
that call.  I.e. if there is I/O pending, then the call is illegal;
if there isn't, it needn't worry.

That is NOT true for VOLATILE, where an object may change at any time,
WITHOUT invoking defined behaviour.

>I never objected to using ASYNCHRONOUS to handle non-blocking data 
>transfers, as you know well. However, I want to (partially) agree with 
>Bill that to truly properly integrate non-blocking operations with the 
>Fortran standard *both* the TARGET and the ASYNCHRONOUS attribute are 
>required for the buffer, both the dummy *and* the actual. The 
>ASYNCHRONOUS attribute does not have guarantees about pointer 
>association persisting across argument passing (this is equivalent to 
>guarantees against copy in/out)...only TARGET does and it is the 
>intended way to allow routines to save pointers to the actual inside a 
>routine (which MPI does). At the same time, TARGET does not allow you to 
>asynchronously change the value of the target. So both are needed.

I am lost.  What do Fortran pointers have to do with MPI?

And, no, the guarantees about pointer association are NOT equivalent
to guarantees against copy in/out - not even remotely.  You are assuming
a particular implementation.

>That said, the ASYNCHRONOUS attribute, or a new attribute with similar 
>semantics, can be extended to include the effects of pointer association 
>argument passing semantics of TARGET.

True.


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




More information about the mpiwg-fortran mailing list