> And I want to remember, that describing WINDOW_IN and WINDOW_OUT
> with the model of a public and a private copy is only a
> trick to educate the user in a easy manner, it is not the
> way MPI_PUT and MPI_GET should be implemented.
> (The only known case, were efficiency is wished but not guaranted
> is the case of 32 bit writes over HIPPI -- here the window must be
> locked, but only for these writes, not for 64 bit writes)
> Therefore I think the current modell is better than the
> "proposal to change the direction of 1-sided comm".
I fully agree with Rolf here. The recent suggestions to change semantics
(progress rules) in order to simplify implementation of 1-sided communications
are detrimental to the applications. I am afraid that they reflect more the
implementor interests (to get it covered with a minimal effort) rather than
the real application needs :-(
The proposals to make get/put collective, require a barrier
synchronization (with fence operation deleted) to complete transfer of the
data, or cooperation of the process that owns the window that put/gets are
targeting make Global Arrays and its MIMD applications virtually impossible
to implement on top of this modified "1-sided" model.
To realize the problem, please imagine a class of producer-consumer
algorithms executed by processes A and B with the items produced/consumed
in the window of process C (which is executing some other subtask
and is unaware of the 1-sided coms targeting its window).
[I tried to post this example before but my message was probably lost -
I am on travel in Europe with limited access to Internet]