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 (non-negative integer) |
| IN origin_datatype | datatype of each entry in origin buffer (handle) |
| IN target_rank | rank of target (non-negative integer) |
| IN target_disp | displacement from start of window to target buffer (non-negative integer) |
| IN target_count | number of entries in target buffer (non-negative 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 (binding deprecated, see Section Deprecated since MPI-2.2
) }
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.
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.)
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.)
Advice to users.
Advice
to implementors.
Up: Communication Calls
Next: Get
Previous: Communication Calls
Return to MPI-2.2 Standard Index
Return to MPI Forum Home Page
(Unofficial) MPI-2.2 of September 4, 2009
HTML Generated on September 10, 2009