Re: MPI code error raises a question

Richard Maine wrote:
> GaryScott <garylscott@[EMAIL PROTECTED]
> wrote:
> 
> 
>>On May 8, 3:40 pm, glen herrmannsfeldt <g...@[EMAIL PROTECTED]
> wrote:
>>
>>>Dick Hendrickson wrote:
>>
>>>As to Dan, I would say that ASYNCHRONOUS variables should only
>>>change between the I/O operation and the appropriate WAIT
>>>statement.  
>>
>>I probably don't understand something, but I would think that an
>>unacceptable restriction.  If this is a fixed memory address used by
>>some asynchronous external processor such as an analog signal input
>>(lets say a 16-bit analog), that processor probably has a regular
>>sample frequency, but is possibly asynchronous with the CPU let alone
>>this asynchronous I/O operation.
> 
> 
> That's not the kind of situation that ASYNCHRONOUS is about. I think
> Glenn threw people off with mentioning that MPI was sort of like I/O.
> While in some sense, that is so, it is irrelevant. ASYNCRONOUS is about
> Fortran read/write statements. It is not about other random ways that
> variables mught change values asynchronously, and it doesn't matter
> whether those other ways are or are not sort of like I/O. If it isn't
> Fortran read/write statements, then the asynchronous attribute is
> irrelevant.
> 
> What you are looking for is the VOLATILE attribute. Memory addresses
> that get updated via means independent of the Fortran program are
> exactly the kind of thing VOLATILE is about.

Yes, I was aware of the I/O meaning for asynchronous.  I was thinking of 
asynchronous I/O of a volatile variable.  In that case, I'd expect the 
volatile variable to continue to be volatile right up to the point that 
it is written.  He indicated that it was (or should be or something) 
prohibited from changing (I thought he was referring to a volatile 
variable) between the initiation of the write sequence and a wait (or 
status test?).  Anyway I'm familiar with asynch I/O with bufferin/out 
that retained "volatility" right up to the point of the transfer. 
That's the way I think it should work.

> 


-- 

Gary Scott
mailto:garylscott@[EMAIL PROTECTED]
 dot net

Fortran Library:  http://www.fortranlib.com

Sup****t the Original G95 Project:  http://www.g95.org
-OR-
Sup****t the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford