mpid_put_contig.tex

刚才是说明 现在是安装程序在 LINUX环境下进行编程的MPICH安装文件

\startmanpage
\mantitle{MPID{\tt \char`\_}Put{\tt \char`\_}contig}{tex}{10/7/2002}
\manname{MPID{\tt \char`\_}Put{\tt \char`\_}contig}
--- Copy local memory to a remote process 
\subhead{Synopsis}
\startvb\begin{verbatim}
int MPID_Put_contig( const void *origin_buf, int n, 
                    MPI_Aint target_offset, int target_rank, MPID_Comm *comm,
                    volatile int *local_flag, MPI_Aint target_flag )

\end{verbatim}
\endvb

\subhead{Input Parameters}
\startarg{buf }{Pointer to local memory to be copied
}
\startarg{n   }{Number of bytes to move
}
\startarg{target{\tt \char`\_}offset }{Location of destination 
}
\startarg{target{\tt \char`\_}rank }{Rank of the destination process in the communicator
}
\startarg{comm }{Communicator
}
\startarg{local{\tt \char`\_}flag }{Address of a flag to be set when this call is locally complete.
}
\startarg{target{\tt \char`\_}flag }{This is an id of a flag at the target process.  This value
must have been specified by the target process in a previous communication
(either with {\tt MPID{\tt \char`\_}Put{\tt \char`\_}contig} or {\tt MPID{\tt \char`\_}Rhcv}).  A value of {\tt 0} indicates no
target completion flag.
}
\par
\subhead{Notes}
This routine is non-blocking.  It is responsible for any flow control.
\par
The {\tt origin{\tt \char`\_}buf} {\em must} be acquired through {\tt MPID{\tt \char`\_}Segment{\tt \char`\_}init{\tt \char`\_}pack}.
This restriction allows {\tt MPID{\tt \char`\_}Put{\tt \char`\_}contig} to assume that the origin
memory is appropriate for the put operation.  However, the generic
implementation of {\tt MPID{\tt \char`\_}Segment{\tt \char`\_}init{\tt \char`\_}pack} will not take any special steps;
an implementation of {\tt MPID{\tt \char`\_}Put{\tt \char`\_}contig} that requires such must also
provide the matching {\tt MPID{\tt \char`\_}Segment{\tt \char`\_}xxx} routines.
\par
The {\tt target{\tt \char`\_}offset} is relative to {\tt MPI{\tt \char`\_}BOTTOM}, and for all expected
ADI implementations is the same as the address of the target memory location.
\par
This routine uses a communicator instead of a window because it may be
used to implement {\em any} kind of data transfer between processes.  For
example, the generic implementation of {\tt MPID{\tt \char`\_}Isend} may use {\tt MPID{\tt \char`\_}Rhcv
}to implement a rendezvous with the destination process and
{\tt MPID{\tt \char`\_}Put{\tt \char`\_}contig} to move the data to the destination once the receive
buffer is allocated.
\par
\subhead{Module}
MPID{\tt \char`\_}CORE
\par
\subhead{Questions}
What addresses are valid for local flags?  What offsets (offsets
because remote locations are specified by offset rather than address,
since a remote system may have a different-sized address) are valid for
target flags?  Should the type of a flag be {\tt MPID{\tt \char`\_}flag{\tt \char`\_}t}?
Do we require a test call on the flag, or only that the local flag be
declared as volatile (as in the prototype)?
\par
My current thinking is to require {\tt MPID{\tt \char`\_}Flag{\tt \char`\_}t}, and provide a routine
to allocate and free them.  The device can easily include one within
an {\tt MPID{\tt \char`\_}Request} structure.  The group voted yes on this, but the
document has not yet been changed to reflect this.
\par
Do we want to require that the buffer be setup with the segment routine,
or is there a separate routine in {\tt MPID{\tt \char`\_}CORE} that should be called for
any data moved with {\tt MPID{\tt \char`\_}Put{\tt \char`\_}contig}?
\par
Do we want more information to be associated with the flags?
For example, each flag could have a list of the processes waiting
on a flag.  My current feeling is that this is up to the
ADI implementation and need not be required of all devices.  That is,
it could be part of the `private' (implementation-specific) data in a flag.
\endmanpage