I said:
>Marc writes that a PUT becomes visible to loads *only* after a call to
>WINDOW_IN. I believe that I understand that it is only *guaranteed* to
>become visible after a call to WINDOW_IN, but may become visible before
>that. (If this is not the case, please correct.)
Marc wrote:
>Your understanding is correct
I asked:
> ....omitted....
>So this suggests that third-party communication *is* supported by having
>one process perform a PUT followed by a FENCE, and another perform a
>GET? Doesn't this mandate the use of an agent at the third party on
>some systems?
Marc wrote:
>Yes, and yes.
>If A does
> Put(to C); fence; send(to B)
>and B does
> receive(from A); Get(from C)
>then the get will return the data set by the put
>On a distributed memory system, where the memory of a node can only be written
>by threads running on that node, then some code was executed at C (by a kernel
>process, by a callback routine, by a signal handler, etc.) after the put of A
>and before the get of B.
In this light, I find this approach to third-party communication unsatisfying
in two ways.
1. It mandates the use of an agent at the third party, but only for the
rare case where the user will use code like the above. Everything else
in this proposal, and in the rest of MPI, does not mandate the use of
an agent.
2. I think that Marc's use of "send" and "recv" in this example is not
accidental. There are very few other portable ways to perform the
synchronization necessary for "B" to know that that "A" has updated "C"
other than sending a message (or performing a global operation). Nothing
is built into one-sided itself to help with this. If "A" above knows
which "B" will be consuming the data (and it must to send the message),
then why bother with "C" at all? Why does "A" not just send the data in
the message, or perform a one-sided communication directly with "B"?
Taken together, these suggest that the expense of supporting this feature
might be high on some systems, but the reward will be small.
If A and B and C are required to take part in some collective operation
between the PUT and the GET, then this problem goes away, and so does the
agent. This is already handled in the BARRIER-portion of the proposal.
-Dave
===============================================================================
David C. DiNucci | MRJ, Inc., Rsrch Scntst |USMail: NASA Ames Rsrch Ctr
dinucci@nas.nasa.gov| NAS (Num. Aerospace Sim.)| M/S T27A-2
(415)604-4430 | Parallel Tools Group | Moffett Field, CA 94035