The execution of a put operation is similar to the execution of a send by the origin process and a matching receive by the target process. The obvious difference is that all arguments are provided by one call --- the call executed by the origin process.
MPI_PUT(origin_addr, origin_count, origin_datatype, target_rank, target_disp, target_count, target_datatype, win) | |
IN origin_addr | initial address of origin buffer (choice) |
IN origin_count | number of entries in origin buffer (nonnegative integer) |
IN origin_datatype | datatype of each entry in origin buffer (handle) |
IN target_rank | rank of target (nonnegative integer) |
IN target_disp | displacement from start of window to target buffer (nonnegative integer) |
IN target_count | number of entries in target buffer (nonnegative integer) |
IN target_datatype | datatype of each entry in target buffer (handle) |
IN win | window object used for communication (handle) |
int MPI_Put(void *origin_addr, int origin_count, MPI_Datatype origin_datatype, int target_rank, MPI_Aint target_disp, int target_count, MPI_Datatype target_datatype, MPI_Win win)
MPI_PUT(ORIGIN_ADDR, ORIGIN_COUNT, ORIGIN_DATATYPE, TARGET_RANK, TARGET_DISP, TARGET_COUNT, TARGET_DATATYPE, WIN, IERROR)
<type> ORIGIN_ADDR(*)
INTEGER(KIND=MPI_ADDRESS_KIND) TARGET_DISP
INTEGER ORIGIN_COUNT, ORIGIN_DATATYPE, TARGET_RANK, TARGET_COUNT, TARGET_DATATYPE, WIN, IERROR
void MPI::Win::Put(const void* origin_addr, int origin_count, const MPI::Datatype& origin_datatype, int target_rank, MPI::Aint target_disp, int target_count, const MPI::Datatype& target_datatype) const
Transfers origin_count successive entries of the type specified by the origin_datatype, starting at address origin_addr on the origin node to the target node specified by the win, target_rank pair. The data are written in the target buffer at address target_addr = window_base + target_disp×disp_unit, where window_base and disp_unit are the base address and window displacement unit specified at window initialization, by the target process.
The target buffer is specified by the arguments target_count and target_datatype.
The data transfer is the same as that which would occur if the origin process executed a send operation with arguments origin_addr, origin_count, origin_datatype, target_rank, tag, comm, and the target process executed a receive operation with arguments target_addr, target_count, target_datatype, source, tag, comm, where target_addr is the target buffer address computed as explained above, and comm is a communicator for the group of win.
The communication must satisfy the same constraints as for a similar message-passing communication. The target_datatype may not specify overlapping entries in the target buffer. The message sent must fit, without truncation, in the target buffer. Furthermore, the target buffer must fit in the target window.
The target_datatype argument is a handle to a datatype object defined at the origin process. However, this object is interpreted at the target process: the outcome is as if the target datatype object was defined at the target process, by the same sequence of calls used to define it at the origin process. The target datatype must contain only relative displacements, not absolute addresses. The same holds for get and accumulate.
Advice to users.
The target_datatype argument is a handle to a datatype object that is defined at the origin process, even though it defines a data layout in the target process memory. This causes no problems in a homogeneous environment, or in a heterogeneous environment, if only portable datatypes are used (portable datatypes are defined in Section Semantic Terms , page Semantic Terms ).
The performance of a put transfer can be significantly affected, on
some systems,
from the choice of window location and the shape and location
of the origin and target buffer: transfers to a target window in memory
allocated by MPI_ALLOC_MEM may be much faster on shared
memory systems;
transfers from contiguous buffers will be
faster on most, if not all, systems; the alignment of the
communication buffers may also impact performance.
( End of advice to users.)
Advice
to implementors.
A high-quality
implementation will attempt to
prevent remote accesses to memory outside the
window that was exposed by the process. This, both for debugging
purposes, and for protection with client-server codes that use RMA.
I.e., a high-quality implementation will check, if possible,
window bounds on each RMA call,
and raise an MPI exception at the origin call if an out-of-bound
situation occurred.
Note that the condition can be checked at the origin.
Of course, the added safety achieved by such checks has to be weighed
against the added cost of such checks.
( End of advice to implementors.)