In re-reading my last message, I realize that things may have become a
bit confused, and that I may have actually been agreeing with both Rolf
and Jarek when it looked like I was disagreeing. So, first let me
restate my (cleaned-up) proposal, then I will extend it.
I suggested that an allocated buffer have an "incoming" attribute which
could have one of two values: "permitted", or "delayed".
* In "permitted" mode, a PUT may or may not become visible to GET
operations and local loads before the process has called WINDOW_IN.
* In "delayed" mode, a PUT will not become visible to GET
operations and local loads before the process has called WINDOW_IN.
(There is no mode which requires that a PUT will become visible to GET
operations and local loads before the process has called WINDOW_IN.)
I now propose that an analogous rule should govern GETs. That is --
Each buffer will have another attribute, "outgoing", with one of two
values: "permitted", or "delayed".
* In "permitted" mode, a GET may or may not see the result of PUT
operations or local stores before the process has called WINDOW_OUT.
* In "delayed" mode, a GET will not see the result of PUT
operations or local stores before the process has called WINDOW_OUT.
(There is no mode which requires that a GET will see the result of
PUT operations or local stores before the process has called
WINDOW_OUT.)
The basic idea here is that if programmers can code using the "permitted"
attributes, their program should be pretty fast and space-efficient on
any architecture. The "delayed" attributes allow programmers to avoid
the uncertainties present when using the "permitted" ones.
Note that a GET from a location in a remote process will only be
guaranteed (by MPI) to return a value which was PUT to that location by
another process if the remote process has called both WINDOW_IN and
WINDOW_OUT, in that order, between the time that it detected the GET
and the time that it detected the PUT. (I think this is the same as
Marc's current proposal.)
Some programmers might "know" that their machine will actually support
completely consistent and coherent updates, so they may want to program
knowing that "permitted" means "visible immediately". For this reason,
I propose the addition of an information routine which returns whether
or not this consistency is present for the communicator/implementation.
(There might be more than one possible level of consistency.)
Programmers who expect more consistency than promised by the MPI
semantics stated above should call this routine to ensure that it is
present. This will allow them to check, in their code, whether their
"almost-MPI" program has been moved to a machine where it won't work.
In my last message, I suggested that programmers might want to change
the incoming attribute of a buffer during execution. It is probably
acceptable to require that the incoming and outgoing attributes be
specified when the buffer is allocated (which will need to be possible
in any case if this approach is used) and to provide no mechanism for
further modifications. (That's two fewer routines already!)
-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