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: [email protected] Tel.: +44 1223 334761 Fax: +44 1223 334679