Re: MPI code error raises a question

In article
<pbJUj.176928$D_3.72496@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
*** Hendrickson <***.hendrickson@xxxxxxx> wrote:

I don't think of MPI as being
an I/O thingo and volatile was designed, more or less,
to allow for surprising changes to variables.

I personally think that I/O *is* an appropriate way to think of
message passing (including MPI). The device happens to be another
computer rather than a simple I/O device (card reader, tape drive,
etc.), but as far as abstractions and how the code should behave,
passing or receiving a message is very close to writing or reading
data from some device.

The problem with nonblocking message passing and f90 is, I think,
twofold. First, there is the asynchronous/volatile aspect where the
compiler must not cache values into registers, or precompute values
in one place and expect them to be the same as computing them later.

Then there is the other problem involving possible copy-in/copy-out
of dummy arguments (usually arrays) with local copies. At some
point in the calling sequence, if a local copy is made of such an
argument, and that address is eventually used in the
asynchronous/volatile way to receive data from a remote node, then
that data will not appear in the actual array but rather in the
local copy (which is unknown to the high-level calling routine). It
would seem that some combination of target/pointer attributes would
be sufficient to prevent such unwanted local copies.

The other problem mentioned, needing millions of interface routines,
I think is not so serious. The system could be designed to always
accept data of some type (say integer arrays), and conversion
routines could be written to coerce any user type into that message
type. In fortran, this could be done with transfer(), for example.
This might require an extra buffer to be used, but memory is cheap
and plentiful in modern computers, so I don't think this is a
serious practical problem.

$.02 -Ron Shepard
.