The current semantics specifies that a put does not become visible by the
window owner until it has executed a WINDOW_IN call. On the other hand, it
bcomes visible to gets as soon as it is complete.
An alternative is to specify that a put becomes visible to any other access,
either local load, or get, only after the call to WINDOW_IN. We get a "delayed
consistency" model for all window updates.
cons:
We cannot use anymore windows for "shared memory" style third-party
communication, where process A and B communicate (using put and get) thru
memory at process C. Process C must be involved. I.e., we restrict put/get
for more message-passing style communication, where put/get is used to move
data produced by the origin (target) process for consumption by the target
(origin) process, while keeping the advantage of put/get that one side provides
all the information on addresses, and the other side need only be involved in
the synchronization.
pros:
We can have now a (low quality -:) MPI implementation with no agents: the
transfer is always affected when the call to WINDOW_IN occurs.
We don't need MPI_FENCE anymore. This, because we gave up on third party
communication, where fence is needed. If the communication always requires
some synchronization with the window owner, then counters or MPI_BARRIER can be
used to make sure that data delivery is complete before it is used.