Re: revised question

William Saphir (wcs@nsgi3.lbl.gov)
Fri, 20 Jun 1997 15:53:25 -0700

On Jun 20, 5:31pm, Marc Snir wrote:
> ***********
> The IN or INOUT designation in the generic binding does not refer to what
> an implementation might do, but to what is the behavior of the functions,
> as
> defined by the standard. If the call modifies the opaque file object in a
> way that is observable to the user, i.e., if the call modifies a property
> of the opaque file
> object that gen be retrieved by an MPI call, then the file handle argument
> is INOUT. Otherwise, it is IN. The implementation is free to update
> information
> associated with a file, even if the file argument is IN, as long as the
> user is not aware of this update.

Code examples are a nice way to explain this, for handles.
In the following, a and b are handles. a has been initialized
to a valid handle, and b has not been initialized.

b = a
MPI_xxx(a)

If the argument to MPI_xxx is IN, then b is valid afterwards
If the argument to MPI_xxx is OUT or INOUT, then b may no longer
be a valid handle.

MPI_xxx(b)

If the argument to MPI_xxx is OUT, this is ok, and the result
does not depend on the value of b.
If the argument fo MPI_xxx is IN or INOUT, this is erroneous.

For buffer arguments, it is a bit more complicated, because
the *location* of the buffer matters even for OUT arguments,
and because the buffer argument itself doesn't uniquely
describe the data.
It is the data described by the (buffer, datatatype) pair
that is IN or OUT.

I'm not sure if MPI is rigorously consistent about this, but it's
the general intent, as I understand it.

Bill