>Barriers are easy to program but efficient only in well balanced
>applications. In the big area of FE applications,
>MPI_PUT and MPI_CONSUME_COUNTER can be more efficient.
I believe that there are only three methods, within MPI, to ensure that a
local fetch on the target process will occur after the PUT and that the
fetch will accept the results of the PUT:
1. The target process could wait until a counter advances
2. Both the origin and target could perform a collective communication
between the PUT and the fetch
3. The origin could send a messsage which must be received at the target
before the fetch
All of these three must be followed (I believe) by a WINDOW_IN before the
fetch, according to the current semantics.
The problem with 3 is that it is undesirable to require the user to perform
message-passing to perform 1-sided communication.
The problem with 1, as I understand it, is that the counter will not be
incremented until the PUT is "felt" at the target, but the PUT cannot be
"felt" at its target until a WINDOW_IN is performed -- so, the counter
cannot increment until a WINDOW_IN is performed. In other words, method
1 doesn't work, because a program cannot wait for the counter to advance and
then issue a WINDOW_IN. The best it can do is poll, repeatedly issuing a
WINDOW_IN and checking the counter in a loop, until the counter is incremented.
So, unless there are changes made to the current semantics, or unless I
misunderstand the semantics, that leaves 2. With 2 being the only option,
it seemed reasonable (but perhaps is more complex that I thought) to attempt
to combine the WINDOW_IN and WINDOW_OUT with the BARRIER. Also, since a
collective operation was required in any case, I suggested the collective
PUT and collective GET.
There are similar problems with MPI_FENCE -- does the FENCE complete before
the target performs a WINDOW_IN? If so, then it is possible for a PUT
to complete on the target without the PUT being "felt" at the target? If
so, what does "complete at the target" mean?
Some possible solutions have been proposed -- i.e. maybe FENCE can be dropped.
Maybe BARRIER and the COUNTER routines can automatically imply WINDOW_IN
and WINDOW_OUT. But it sounds like some vendors may have difficulty
implementing such models, and I will only be convinced that these solutions
work when I see the vendors agree on what they are promising the programmer.
So, we are back to trying to find a portable model that vendors can implement.
I think that the collective model might be one.
>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.
If they are meant as an educational tool, I think that they are failing.
If they are not required to implement a GET/PUT model, I hope we can find
ways to remove them from the semantics. If they are required, I hope that
I can find out just when to use them and what their effect will be.
>Therefore I think the current modell is better than the
>"proposal to change the direction of 1-sided comm".
If we keep the current model, I hope that we can answer the above questions.
David C. DiNucci | MRJ, Inc., Rsrch Scntst |USMail: NASA Ames Rsrch Ctr
firstname.lastname@example.org| NAS (Num. Aerospace Sim.)| M/S T27A-2
(415)604-4430 | Parallel Tools Group | Moffett Field, CA 94035