size in MPI-MEM_ALLOC should be MPI_AINT.
YES -- I made the change. We may want to malloc more than 2 GB, and
implementations are free to return an error if they can allocate only up to
2 GB. (an error can always be returned iof the user ask for too much
memory)..
disp_unti in MPI_WIN_INIT should be MPI_Aint
NO - I see no reason. Displacement unit is, basically, sizeof(type), where
type is the basic component of the window. I expect this to be an int.
MPI_WIN_INIT has also the side-effect of a call to MPI_WIN_BARRIER.
Harmless, but does it matter?
Restriction on non-overlapping target datatype for accumulate should aslo
apply to target of put or origin of get.
YES - the same restrictions as for send-receive should hold. I made the
change.
MPI_WIN_BARRIER should imply MPI_BARRIER
NO; we discussed this at length, and the decision was for weaker
synchronization. All the RMA synchronization calls are synchronizing RMA
operations, but avoid to promise more.
clarification on what can block in a START, PUT, COMPLETE sequence.
OK, will try to improve prose. Jusdt to make sure people understand the
current text: I assume that the following code may not deadlock
process 0 process 1
start post
put
send ---> recv
complete wait
I.e., an implementation cannot just postpone the execution of the put until
a wait occurred on the target. This is, essentially, the same point as
made by Figure 5.6 in the current text (I may add the axample above, for
further clarification). This is a standard problem with MPI
implementations, in general: whenever a process blocks in a blocking MPI
call, the MPI library must continue to make progress on all enabled
communications, not only the communication related to the call that
blocked. Thus, when process 1 blocks at the receive call, it has to
continue pulling data of the put. This will enable the put to complete,
the send to occur, the receive to complete, the wait to occur, and so on.
Clarification in what can block in a sequence lock, put, unlock
ibid
Sequential consistency and RMA
This needs a longer answer -- toimorrow, I hope.