MPI_WIN_LOCK(lock_type, rank, assert, win)
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
int MPI::Win::Lock(int lock_type, int rank, int assert) const
void
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)INTEGER RANK, WIN, IERROR
int MPI::Win::Unlock(int rank) const
void
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.
Implementors may restrict the use of RMA/ communication that is
synchronized by lock calls to windows in memory allocated by
MPI_ALLOC_MEM
(Section 4.11, page ).
Locks can be used portably only in such memory.
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.)
Consider the sequence of calls in the example below.
MPI_Win_lock(MPI_LOCK_EXCLUSIVE, rank, assert, win) MPI_Put(..., rank, ..., win) MPI_Win_unlock(rank, win)
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-Standard for MARMOT