The initialization operation allows each process in an intracommunicator group to specify, in a collective operation, a ``window'' in its memory that is made accessible to accesses by remote processes. The call returns an opaque object that represents the group of processes that own and access the set of windows, and the attributes of each window, as specified by the initialization call.
| MPI_WIN_CREATE(base, size, disp_unit, info, comm, win) | |
| IN base | initial address of window (choice) |
| IN size | size of window in bytes (non-negative integer) |
| IN disp_unit | local unit size for displacements, in bytes (positive integer) |
| IN info | info argument (handle) |
| IN comm | communicator (handle) |
| OUT win | window object returned by the call (handle) |
int MPI_Win_create(void *base, MPI_Aint size, int disp_unit, MPI_Info info, MPI_Comm comm, MPI_Win *win)
MPI_WIN_CREATE(BASE, SIZE, DISP_UNIT, INFO, COMM, WIN, IERROR)
<type> BASE(*)
INTEGER(KIND=MPI_ADDRESS_KIND) SIZE
INTEGER DISP_UNIT, INFO, COMM, WIN, IERROR
{ static MPI::Win MPI::Win::Create(const void* base, MPI::Aint size, int disp_unit, const MPI::Info& info, const MPI::Intracomm& comm) (binding deprecated, see Section Deprecated since MPI-2.2
) }
This is a collective call executed by all processes in the group of
comm. It returns a window object that can be used by these
processes to perform RMA operations. Each process specifies
a window of existing memory that it exposes to RMA accesses by the
processes in the group of
comm.
The window consists of size bytes,
starting at address base.
A process may elect to expose no memory by
specifying size = 0.
The displacement unit argument
is provided to facilitate address arithmetic in RMA
operations: the target displacement argument of an RMA operation is
scaled by the factor disp_unit specified by the target
process, at window creation.
The window size is specified using an address sized integer, so as to
allow windows that span more than 4 GB of address space. (Even if
the physical memory size is less than 4 GB, the address range
may be larger than 4 GB, if addresses are not contiguous.)
( End of rationale.)
Common choices for disp_unit
are 1 (no scaling), and (in C syntax) sizeof(type), for a
window that consists of an array of elements of type type. The
later choice will allow one to use array indices in RMA calls, and have those scaled correctly to byte displacements, even in a heterogeneous environment.
( End of advice to users.)
A window can be created in any part of the process memory. However,
on some systems, the performance of windows in
memory allocated by MPI_ALLOC_MEM
(Section Memory Allocation
,
page Memory Allocation
) will be better.
Also, on some systems, performance is improved when window boundaries
are aligned at ``natural'' boundaries (word, double-word, cache line,
page frame, etc.).
( End of advice to users.)
In cases where RMA operations use different mechanisms in different
memory areas (e.g., load/store in a shared memory segment, and an
asynchronous handler in private memory), the MPI_WIN_CREATE
call needs to figure out which type of memory is used for the
window. To do so, MPI maintains, internally, the
list of memory segments allocated by MPI_ALLOC_MEM, or by
other, implementation specific, mechanisms, together with information
on the type of memory segment allocated. When a call to
MPI_WIN_CREATE occurs, then MPI checks which segment
contains each window, and decides, accordingly, which mechanism to use
for RMA operations.
2.2
Vendors may provide additional, implementation-specific mechanisms to
allocate or to specify memory regions that are preferable for use in
one-sided communication. In particular, such mechanisms can be used to
place static variables into such preferred regions.
Implementors should document any performance impact of window alignment.
( End of advice to implementors.)
int MPI_Win_free(MPI_Win *win)
MPI_WIN_FREE(WIN, IERROR)
{ void MPI::Win::Free() (binding deprecated, see Section Deprecated since MPI-2.2
) }
Frees the window object win and returns a null handle
(equal to MPI_WIN_NULL).
This is a collective call executed by all processes in the group
associated with win. MPI_WIN_FREE(win) can be
invoked by a process only after it has completed its involvement in
RMA communications on window win: i.e., the process has
called MPI_WIN_FENCE, or called
MPI_WIN_WAIT to match a previous call to
MPI_WIN_POST or called MPI_WIN_COMPLETE to
match a previous call to MPI_WIN_START or called
MPI_WIN_UNLOCK to match a previous call to
MPI_WIN_LOCK.
When the call returns, the window memory can be freed.
MPI_WIN_FREE requires a barrier synchronization: no process
can return from free until all processes in the group of win
called free. This, to ensure that no process will attempt to access a
remote window (e.g., with lock/unlock) after it was freed.
( End of advice to implementors.)
Rationale.
Advice to users.
The info argument provides
optimization hints to the runtime about the expected
usage pattern of the window.
The following info key is predefined:
The various processes in the group of
comm may specify completely different
target windows, in location, size, displacement units and info arguments.
As long as all the get, put and accumulate accesses
to a particular process fit their
specific target window this should pose no problem.
The same area in memory may appear in multiple windows, each
associated with a different window object. However, concurrent
communications to distinct, overlapping windows may lead to
erroneous results.
Advice to users.
Advice
to implementors.
MPI_WIN_FREE(win) INOUT win window object (handle)
INTEGER WIN, IERROR
Advice
to implementors.
Up: Initialization
Next: Window Attributes
Previous: Initialization
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