February 2009 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPI3 Fortran] MPI buffer arguments - void and call-by-reference
by Craig Rasmussen 17 Feb '09

17 Feb '09

After the J3 meeting in Las Vegas last week I think we are reaching a conclusion on many of the MPI 3 interface issues. The one remaining point of disagreement is whether to use the ASYNCHRONOUS attribute (currently it only applies to Fortran IO) or the VOLATILE attribute. Since there is so much disagreement on this issue within J3 and WG5 (this includes disagreements between several influential members on the committees and some even switching sides from time to time), I'll leave the solution for later. As for now, I believe that the MPI Forum should disregard the J3 paper I send to you earlier, supposedly clarifying the asynchronous MPI question. We do have clarity on another issue, however. There was substantial agreement on the committee for the following interface (I was the lone dissenting vote): interface subroutine MPI_Send(buf, ...) BIND(C) TYPE(*), DIMENSION(..), INTENT(in) :: buf ... end subroutine end interface This means that actual argument associated with the dummy argument buf, can be an array or scalar of any type. If it is an array, it can have any rank. The major impact to the MPI implementation is that the buf argument will be passed by descriptor. This means that there will be no copyin/copyout of the array by the Fortran compiler. The MPI implementation is free to enforce whatever semantics it wishes on the buf argument. In your example below, CALL MPI_SEND(rarr(5:30:3),...) the MPI implementation can get the address of the rarr array and the 5:30:3 index information. It can choose to return an error if it wishes to enforce that the array is contiguous or it can ignore the stride by 3 information and just proceed as if the array was contiguous. I'm pretty sure this will be the only choice provided in Fortran 2008/ Interop TR and MPI 3.0 timeframe. Otherwise the MPI Forum can use the CLOC() intrinsic in the current 2003 interoperability standard to pass void* buffer addresses. I think using TYPE(*) and DIMENSION(..) is an excellent solution for MPI 3.0. The advantages are: 1. Current user code won't have to change beyond using the MPI3 module. 2. The interface is non-generic and doesn't have the interface explosion in the current MPI 90 interfaces. This interface will even accept scalar actuals. 3. The interface is type safe as far as the other (non void*) arguments. 4. The actual argument associated with buf doesn't require the TARGET attribute (as the CLOC/C_PTR route does), with the possibly substantial performance implications. Potential downside: 1. There must be a wrapper that calls the MPI C implementation. We had decided on this anyway as we wanted to stick with the SUBROUTINE syntax. 2. There will be some minor performance implications as the array descriptor must be examined before calling the MPI C implementation. The performance hit can be as minor as dereferencing a struct to get at the array address to something more substantial if the implementation wants to make use of the stride information. I'm hoping we can look at this in more detail at the next MPI Forum meeting and reach agreement on the non-asynchronous interfaces. We can also discuss MPI_Isend and MPI_Irecv and what to do with them. I'm assuming that the use of ASYNCHRONOUS plus TARGET will be preferred over VOLATILE. Since at this point ASYNCHRONOUS really only pertains to Fortran IO, MPI Forum could request another name for an equivalent attribute, perhaps one that combines the semantics of ASYNCHRONOUS and TARGET. Cheers, Craig On Feb 9, 2009, at 3:59 PM, Rolf Rabenseifner wrote: > This is the second part of my two mails: > > B) VOID buffer declaration > -------------------------- > > B.1 Current status > > INTEGER :: ibuf > CALL MPI_SEND(ibuf,...) > > REAL, DIMENSION(100) :: rarr > CALL MPI_SEND(rarr,...) > CALL MPI_SEND(rarr(5:30:3),...) > > COMPLEX, DIMENSION(10,20,30) :: carr3dim > CALL MPI_SEND(carr3dim,...) > > TYPE buff_type > SEQUENCE > INTEGER, DIMENSION(3):: i_val > DOUBLE PRECISION, DIMENSION(5):: d_val > END TYPE buff_type > TYPE (buff_type) :: struct > CALL MPI_SEND(struct,...) > > TYPE (buff_type), DIMENSION(10,20) :: struct2dim > CALL MPI_SEND(struct2dim,...) > > ... ... ... ... > > All this works and the C-writte MPI_SEND receives the address > of the first data element of each buffer. > > Currently, there isn't a F90 interface definition > (i.e. only F77 style is used) > > MPI has its own interface to handle the data structure behind > the starting pointer, the so called MPI datatypes. > Such an MPI datatype need not to describe the whole > structure, i.e., there may be differences between the > type information that was told the compiler and the MPI datatype > information. > > > B.2 Goals > > B.2.1 To allow F90 interfaces that do not break eisting codes > B.2.2 To minimize the burden for MPI libraries implementers > and Fortran compiler implementers. > > B.3 Maybe a simple but efficient solution > > SUBROUTINE MPI_SEND(buf,... > VOID :: buf > END > > This can be used only in a interface definition for routines > that are implemented in C. > There is no meaning if one wants to write the routine MPI_SEND > in Fortran. > > Meaning of VOID buf: > Exactly the same as if implicit (F77) interfaces are used. > > (Not needed for MPI, but a possible extension: > > Instead of VOID, one is using IMPLARG, meaning the > same as VOID on the caller side and is also allowed > on the soubroutine side. > Meaning: Same argument handlich as with implicit interfaces, > i.e., handing over the pointer to the data or > in cases of noncontiguos subarrays only a pointer to > a contiguous copy of the data. > ) > > > C) Call by reference and not by in-copy-out-copy > ------------------------------------------------ > > It is clear, that F77 interfaces cannot do strided arrays > directly with call-by-reference. > > For contiguous arrays and non-arrays, it isn't a problem. > > Fortran compilers are allowed to choose call-by-incopy-and-outcopy > instead of call-by-reference. > > Maybe the following additional option may solve the problem: > > SUBROUTINE MPI_SEND(buf,... > VOID, CALLBYREFERENCE :: buf > > Meaning: Same as what currently done, i.e., call-by-reference > on the caller side, if call-by-reference is possible (i.e., > not for non-contiguous subarrays) > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [MPI3 Fortran] MPI buffer arguments - void and call-by-reference
by Bill Long 17 Feb '09

17 Feb '09

Aleksandar Donev wrote: > Bill Long wrote: >> On the surface, the main area of difference between VOLATILE and >> ASYNCHRONOUS is that a standard-conforming program is not allowed to >> improperly reference or define an asynchronous variable in a part of >> the code where it is subject to asynchronous activity. > There is nothing "on the surface" about this---it is a core and > important difference as I already explained. Just like coarrays are > rather distinct from VOLATILEs, so are targets of async I/O. I don't > care if Cray's compiler treats them the same internally, that is a > quality of implementation issue. But the semantics are rather different. > The "On the surface" part was explained in the sentence that followed the one you quoted. Unlike ASYNCHRONOUS, a VOLATILE variable may be referenced or defined at the same time as when it is being affected by some other agent. However, if you, indeed, don't code any such references or definitions (i.e. follow the asynchronous coding rules), then it does not really matter whether the variable is declared VOLATILE or ASYNCHRONOUS. Cheers, Bill -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

1 0

Re: [MPI3 Fortran] MPI buffer arguments - void and call-by-reference
by Bill Long 17 Feb '09

17 Feb '09

N.M. Maclaren wrote: > On Feb 16 2009, Bill Long wrote: >> >>> Ugh. I have thought of a case where even VOLATILE doesn't block >>> copy-in/copy-out, but it's irrelevant to this debate. >> >> That it is irrelevant is reassuring, although it would be interesting >> to see the case. If it were relevant, then ASYNCHRONOUS would be >> ineffective as well. Copy-in/copy-out is blocked by two constraints >> in the standard (C1232 and C1233) in which VOLATILE and ASYNCHRONOUS >> are interchangeable. In regards to how they affect copy-in/copy-out, >> these two attributes are identical. > > That's almost true, though I can produce cases where ASYNCHRONOUS allows > copy-in/copy-out and VOLATILE doesn't; again, I am 99% sure all of them > are irrelevant. > > The example I originally referred to is the following: > > SUBROUTINE Fred > REAL, VOLATILE :: array(10,10) > INTEGER :: n > DO n = 1,10 > CALL Joe(array(n,:)) > END DO > CONTAINS > SUBROUTINE Joe (arg) > REAL, VOLATILE :: arg(10) > ... > END SUBROUTINE Joe > END SUBROUTINE Fred This program directly violates C1232. The same program with VOLATILE replaced buy ASYNCHRONOUS violates the same constraint. Neither is a valid Fortran subprogram and the compiler is free to not produce any object code. > > >> In the cases relevant to the MPI discussion, there is essentially no >> difference between VOLATILE and ASYNCHRONOUS is regards to code >> motion across a call site. The caller cannot tell if the callee >> contains a WAIT statement, and even if it could, would be hard >> pressed to determine if that particular WAIT statement had anything >> to do with a particular asynchronous variable. Effectively, all >> motion of code involving a variable with either the volatile or >> asynchronous attributes across a call site is suppressed by the >> optimizer. The difference is that a variable can get the >> ASYNCHRONOUS attribute implicitly, whereas VOLATILE must be >> explicitly specified. > > That's not true. It is true only for external calls (i.e. to procedures > of properties unknown to the compiler). Which is exactly why I started the paragraph with "In the cases relevant to the MPI discussion...". All of the calls to MPI routines are external calls. Before laying our flame bait like "That's not true", it would really help if you actually read the paragraph to which you are replying. > >> The definitions and references of volatile variables that the are >> exceptional (compared to nonvolatile variables) are, by their nature, >> asynchronous. The core difference between VOLATILE and ASYNCHRONOUS >> is that the compiler knows exactly where the asynchronous activity is >> coming from - the Fortran I/O system. Since the I/O system is part >> of the processor, it might be able to narrow the scope of >> optimization suppression compared to the volatile case. But, as >> noted above, for a standard-conforming program, the cases where this >> makes an actual difference are slim. > > Really? Consider a program that transfers into a buffer, does a > decomposition/FFT/whatever on it, and transfers it out again. A very > common paradigm. If the compiler can 'see' the source of the code that > does the decomposition/FFT/whatever, and can tell that there is nothing > in it that could change the pending status, it can optimise ASYNCHRONOUS > just like ordinary data. But it can't do that for VOLATILE. That analysis is valid as long as ASYNCHRONOUS is limited to Fortran I/O as is the case currently. Then the compiler "can tell", as you note (assuming it can 'see' the source). Remove the restriction that ASYNCHRONOUS is tied to Fortran I/O and the analysis falls apart. A good argument for not using ASYNCHRONOUS for MPI routines. -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

1 0

Re: [MPI3 Fortran] MPI buffer arguments - void and call-by-reference
by N.M. Maclaren 16 Feb '09

16 Feb '09

On Feb 16 2009, Aleksandar Donev wrote: > >> I am lost. What do Fortran pointers have to do with MPI? > >Surely it has to do with C pointers (did I ever qualify with Fortran >specifically?)? Because you referred to their association status. Fortran pointers have one; C pointers don't. > Where do you get from the Fortran standard, including >the C interop chapter, that if you take a pointer inside a C routine >(MPI) and keep it, you can use it to change the value of the actual >after the call completes??? Oh, I didn't make that assumption - no fear! Despite the fact that it is done in C.2.3 in Annex C :-) This debate is largely about how to enable that facility. > If a Fortran pointer is the target of a C >pointer, it has to have the TARGET attribute---see clause 15 in F2003. You mean 15.1.2.5 (C_LOC)? I don't think that means what bit looks as if it does, but let's skip that for now. Let's just note that your belief that TARGET is the way to do that means that the example in C.2.3 is broken :-) I am not adamantly opposed to the use of TARGET, because it is definitely plausible. I still don't think that it helps, but need to research the standard to be sure. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

1 0

Re: [MPI3 Fortran] MPI buffer arguments - void and call-by-reference
by Aleksandar Donev 16 Feb '09

16 Feb '09

N.M. Maclaren wrote: > I am lost. What do Fortran pointers have to do with MPI? Surely it has to do with C pointers (did I ever qualify with Fortran specifically?)? Where do you get from the Fortran standard, including the C interop chapter, that if you take a pointer inside a C routine (MPI) and keep it, you can use it to change the value of the actual after the call completes??? If a Fortran pointer is the target of a C pointer, it has to have the TARGET attribute---see clause 15 in F2003. Aleks

1 0

Re: [MPI3 Fortran] MPI buffer arguments - void and call-by-reference
by Aleksandar Donev 16 Feb '09

16 Feb '09

Bill Long wrote: > On the surface, the main area of difference between VOLATILE and > ASYNCHRONOUS is that a standard-conforming program is not allowed to > improperly reference or define an asynchronous variable in a part of the > code where it is subject to asynchronous activity. There is nothing "on the surface" about this---it is a core and important difference as I already explained. Just like coarrays are rather distinct from VOLATILEs, so are targets of async I/O. I don't care if Cray's compiler treats them the same internally, that is a quality of implementation issue. But the semantics are rather different. Aleks

1 0

Re: [MPI3 Fortran] MPI buffer arguments - void and call-by-reference
by N.M. Maclaren 16 Feb '09

16 Feb '09

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(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

1 0

Re: [MPI3 Fortran] MPI buffer arguments - void and call-by-reference
by N.M. Maclaren 16 Feb '09

16 Feb '09

On Feb 16 2009, Bill Long wrote: > >> Ugh. I have thought of a case where even VOLATILE doesn't block >> copy-in/copy-out, but it's irrelevant to this debate. > >That it is irrelevant is reassuring, although it would be interesting to >see the case. If it were relevant, then ASYNCHRONOUS would be >ineffective as well. Copy-in/copy-out is blocked by two constraints in >the standard (C1232 and C1233) in which VOLATILE and ASYNCHRONOUS are >interchangeable. In regards to how they affect copy-in/copy-out, these >two attributes are identical. That's almost true, though I can produce cases where ASYNCHRONOUS allows copy-in/copy-out and VOLATILE doesn't; again, I am 99% sure all of them are irrelevant. The example I originally referred to is the following: SUBROUTINE Fred REAL, VOLATILE :: array(10,10) INTEGER :: n DO n = 1,10 CALL Joe(array(n,:)) END DO CONTAINS SUBROUTINE Joe (arg) REAL, VOLATILE :: arg(10) ... END SUBROUTINE Joe END SUBROUTINE Fred Because no part of array is ever used after the first time it is passed to another procedure, the compiler need not ensure that the array used as an argument is the same one as originally allocated in Fred, because using copy-in/copy-out would make not difference to the result of the program. The cases I referred to where ASYNCHRONOUS allows it and VOLATILE doesn't are similar in design. >In the cases relevant to the MPI discussion, there is essentially no >difference between VOLATILE and ASYNCHRONOUS is regards to code motion >across a call site. The caller cannot tell if the callee contains a >WAIT statement, and even if it could, would be hard pressed to determine >if that particular WAIT statement had anything to do with a particular >asynchronous variable. Effectively, all motion of code involving a >variable with either the volatile or asynchronous attributes across a >call site is suppressed by the optimizer. The difference is that a >variable can get the ASYNCHRONOUS attribute implicitly, whereas VOLATILE >must be explicitly specified. That's not true. It is true only for external calls (i.e. to procedures of properties unknown to the compiler). If the call is to an intrinsic procedure, an internal procedure with no external calls or asynchronous I/O statements, or even another file (with global optimisation) that has to external calls or asynchronous I/O statements, then ASYNCHRONOUS is no barrier to using copy-in/copy-out. That could be a MAJOR performance gain in some programs. >The definitions and references of volatile variables that the are >exceptional (compared to nonvolatile variables) are, by their nature, >asynchronous. The core difference between VOLATILE and ASYNCHRONOUS is >that the compiler knows exactly where the asynchronous activity is >coming from - the Fortran I/O system. Since the I/O system is part of >the processor, it might be able to narrow the scope of optimization >suppression compared to the volatile case. But, as noted above, for a >standard-conforming program, the cases where this makes an actual >difference are slim. Really? Consider a program that transfers into a buffer, does a decomposition/FFT/whatever on it, and transfers it out again. A very common paradigm. If the compiler can 'see' the source of the code that does the decomposition/FFT/whatever, and can tell that there is nothing in it that could change the pending status, it can optimise ASYNCHRONOUS just like ordinary data. But it can't do that for VOLATILE. > It is a reasonable and conforming implementation >to just make ASYNCHRONOUS a synonym for VOLATILE. If we want to extend >ASYNCHRONOUS to apply outside the Fortran I/O environment (such as for >MPI non-blocking transfers), then that main distinction is lost. This >is, among others, a reason for opposition to this approach. And it is a reasonable and conforming implementation to take advantage of the difference to optimise ASYNCHRONOUS but not VOLATILE, as I describe above. Locking that out is, among others, a reason for opposing the use of VOLATILE. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

1 0

Re: [MPI3 Fortran] MPI buffer arguments - void and call-by-reference
by Aleksandar Donev 16 Feb '09

16 Feb '09

Hi, > 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). > 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. 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. 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. Best, Aleks

1 0

Re: [MPI3 Fortran] MPI buffer arguments - void and call-by-reference
by Bill Long 16 Feb '09

16 Feb '09

N.M. Maclaren wrote: >> 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. > > Ugh. I have thought of a case where even VOLATILE doesn't block > copy-in/copy-out, but it's irrelevant to this debate. That it is irrelevant is reassuring, although it would be interesting to see the case. If it were relevant, then ASYNCHRONOUS would be ineffective as well. Copy-in/copy-out is blocked by two constraints in the standard (C1232 and C1233) in which VOLATILE and ASYNCHRONOUS are interchangeable. In regards to how they affect copy-in/copy-out, these two attributes are identical. In the cases relevant to the MPI discussion, there is essentially no difference between VOLATILE and ASYNCHRONOUS is regards to code motion across a call site. The caller cannot tell if the callee contains a WAIT statement, and even if it could, would be hard pressed to determine if that particular WAIT statement had anything to do with a particular asynchronous variable. Effectively, all motion of code involving a variable with either the volatile or asynchronous attributes across a call site is suppressed by the optimizer. The difference is that a variable can get the ASYNCHRONOUS attribute implicitly, whereas VOLATILE must be explicitly specified. On the surface, the main area of difference between VOLATILE and ASYNCHRONOUS is that a standard-conforming program is not allowed to improperly reference or define an asynchronous variable in a part of the code where it is subject to asynchronous activity. The program can reference or define variables declared VOLATILE with many fewer restrictions. Of course, if you do not have any references or definitions of the variable in a particular region of the code, then it does not matter which way it was declared. The definitions and references of volatile variables that the are exceptional (compared to nonvolatile variables) are, by their nature, asynchronous. The core difference between VOLATILE and ASYNCHRONOUS is that the compiler knows exactly where the asynchronous activity is coming from - the Fortran I/O system. Since the I/O system is part of the processor, it might be able to narrow the scope of optimization suppression compared to the volatile case. But, as noted above, for a standard-conforming program, the cases where this makes an actual difference are slim. It is a reasonable and conforming implementation to just make ASYNCHRONOUS a synonym for VOLATILE. If we want to extend ASYNCHRONOUS to apply outside the Fortran I/O environment (such as for MPI non-blocking transfers), then that main distinction is lost. This is, among others, a reason for opposition to this approach. Cheers, Bill > > I am also pretty sure that I can construct an example where TARGET > isn't enough to make MPI non-blocking transfers safe, but would need > to check that with the standard very carefully. > > > Regards, > Nick Maclaren, > University of Cambridge Computing Service, > New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. > Email: nmm1(a)cam.ac.uk > Tel.: +44 1223 334761 Fax: +44 1223 334679 > -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

1 0