1. I added the text on error handling.
2. I changed the Fortran binding of MEM_FREE so that it takes a choice
argument. I.e., we now have
POINTER (P, A(100,100))
CALL MPI_MALLOC_MEM(40000, MPI_INFO_NULL, P, IERR)
...
CALL MPI_FREE_MEM(A, IERR)
The malloc call is passed a pointer (a fortran integer) and returns (the
integer cast of) an address. The free call is passed a variable at this
address. This is in line with the C binding.
3. I added text concerning the interaction between locks and 2-party
communication. This last issue is important, so I repeat here the
discussion in the chapter
%%%%%%%%%%%%%%
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.
Advice to users: Users need to use explicit synchronization code in order
to enforce mututal exclusion between locking periods and exposure periods
in a window.
Discussion:
The last paragraphs deal with an issue that I
believe we have not fully addressed before; namely the interaction between
different RMA synchronization mechanisms. Only the interaction
between locks and between post-wait is problematic, since this is a
case where the conflicting calls occur at distinct processes.
Consider the following code template
process 0 process 1 process 2
post(1) start(0) lock(0)
... put(0) put(0)
wait complete unlock
My choice is to say this code is erroneous: the user is responsibel to
ensure that a window is not locked while it is exposed to
RMA access in a 2-party communication.
The alternatives would be
(i) declare the code
above correct and assume that the put of process 2 can be concurrent
with the put of process 1. But this may complicate the implementation
of RMA communication: the wait call may return while there is a pending put
(the
put of process 2) and it cannot anymore complete all ongoing puts that
target the window at process 0.
(ii) declare the code correct and require that
MPI enforce mutual exclusion -- delaying the put of process 2 until
wait completed, or delaying the put of process 1 until
unlock completed. But this may complicate the synchronization required for
locks or
of post-start-wait-complete.
My rationale for declaring the code erroneous is that we should not
toil to support what is likely to be a rare programming style. MPI deals
with correct synchronization when a unique
synchronization mechanism is used. The user deals with synchronization
when the synchronization mechanism
for RMA accesses to a window is changed.