| MPI_WIN_LOCK(lock_type, rank, assert, win) | |
| IN lock_type | either MPI_LOCK_EXCLUSIVE or MPI_LOCK_SHARED (state) |
| IN rank | rank of locked window (non-negative integer) |
| IN assert | program assertion (integer) |
| IN win | window object (handle) |
int MPI_Win_lock(int lock_type, int rank, int assert, MPI_Win win)
MPI_WIN_LOCK(LOCK_TYPE, RANK, ASSERT, WIN, IERROR)
INTEGER LOCK_TYPE, RANK, ASSERT, WIN, IERROR
{ void MPI::Win::Lock(int lock_type, int rank, int assert) const (binding deprecated, see Section Deprecated since MPI-2.2
) }
Starts an RMA access epoch. Only the window at the
process with rank rank can be accessed by RMA operations on win during that epoch.
int MPI_Win_unlock(int rank, MPI_Win win)
MPI_WIN_UNLOCK(RANK, WIN, IERROR)
{ void MPI::Win::Unlock(int rank) const (binding deprecated, see Section Deprecated since MPI-2.2
) }
Completes an RMA access epoch started by a call to MPI_WIN_LOCK(...,win). RMA operations issued during this
period will have completed both at the origin and at the target when
the call returns.
Locks are used to protect accesses to the locked target
window effected by RMA calls issued between the lock and unlock
call, and to protect local
load/store accesses to a locked local window executed between the lock and unlock call.
Accesses that are protected by an exclusive lock
will not be concurrent at the window site
with other accesses to the same window that are lock protected.
Accesses that are protected by a shared lock will not be
concurrent at the window site with
accesses protected by an exclusive lock to the same window.
It is erroneous to have a window locked and exposed (in an exposure
epoch) concurrently. I.e., a process may not call
MPI_WIN_LOCK to lock a target window if the target process
has called MPI_WIN_POST and has not yet called
MPI_WIN_WAIT; it is erroneous to call
MPI_WIN_POST while the local window is locked.
An alternative is to require MPI to enforce mutual exclusion between exposure epochs and locking periods. But this would entail additional
overheads when locks or active target synchronization do not interact
in support of those rare interactions between the two mechanisms. The
programming style that we encourage here is that a set of windows is
used with only one synchronization mechanism at a time, with shifts
from one mechanism to another being rare and involving global synchronization.
( End of rationale.)
Users need to use explicit synchronization code in order to enforce
mutual exclusion between locking periods and exposure epochs on a
window.
( End of advice to users.)
Implementors may restrict the use of RMA communication that is
synchronized by lock calls to windows in memory allocated by
MPI_ALLOC_MEM
(Section Memory Allocation
, page Memory Allocation
).
Locks can be used portably only in such memory.
The implementation of passive target communication when memory is not shared
requires an asynchronous
agent. Such an agent can be implemented more easily, and can achieve
better performance, if restricted to specially allocated memory. It
can be avoided altogether if shared memory is used. It seems natural to
impose restrictions that allows one to use shared memory for 3-rd
party communication in shared memory machines.
The downside of this decision is that passive target communication cannot be
used without taking advantage of nonstandard Fortran features: namely,
the availability of C-like pointers; these are not supported by some
Fortran
compilers (g77 and Windows/NT compilers, at the time of writing).
Also, passive target communication cannot be portably
targeted to COMMON blocks, or other statically declared
Fortran arrays.
( End of rationale.)
The call to MPI_WIN_UNLOCK will not return until the put
transfer has completed at the origin
and at the target.
This still leaves much freedom to implementors.
The call to
MPI_WIN_LOCK may block until an
exclusive lock on the window is acquired; or, the call
MPI_WIN_LOCK may not block, while the call
to MPI_PUT blocks until a lock is acquired; or, the first
two calls may not block, while MPI_WIN_UNLOCK blocks until
a lock is acquired --- the update of the target window is then
postponed until the call to MPI_WIN_UNLOCK occurs.
However, if the call to MPI_WIN_LOCK is used to lock a
local window, then the call must block until the lock is acquired,
since the lock may protect local load/store accesses to the window issued
after the lock call returns.
MPI_WIN_UNLOCK(rank, win) IN rank rank of window (non-negative integer) IN win window object (handle)
INTEGER RANK, WIN, IERROR
Rationale.
Advice to users.
Rationale.
Consider the sequence of calls in the example below.
Example
MPI_Win_lock(MPI_LOCK_EXCLUSIVE, rank, assert, win)
MPI_Put(..., rank, ..., win)
MPI_Win_unlock(rank, win)
Up: Synchronization Calls
Next: Assertions
Previous: General Active Target Synchronization
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