The counter is not part of the "public/privat copy" modell.
There is no direct access to the counter by local store or load.
The counter is only accessible by MPI functions.
The time, when the counter is updated in the target process is
determined by the time, when the PUT/GET at the origin is made
and when it completes at the target. The completion of a PUT is
done only in the "public copy".
WINDOW_IN or WINDOW_OUT is called by the application in the
target process.
With PUT the rules say that the application must call WINDOW_IN
after the PUT has completed at the target. The application can test
the completion or can wait for the completion with MPI_GET_COUNTER
or MPI_CONSUME_COUNTER.
> If so, does that mean that the counter in
> the target can be updated before PUT data appears in the user's window?
> Or do the counter routines automatically perform a WINDOW_IN or
> WINDOW_OUT (and if so, which one)? If the counter cannot update until a
> WINDOW_IN is performed, then is there a way for the target to know, using
> a counter, when it is time to execute a WINDOW_IN without polling?
These questions are therefore obsolete.
> (2) Is there a way for the target to know when the originator has completed
> a FENCE, so that the target can know when to perform a WINDOW_IN (other
> than to use a BARRIER between the FENCE on the originator and the
> WINDOW_IN on the target)? If not, then is it useful?
FENCE is defined for access of multiple processes to one location
in a "third" process. Then normally none of the process uses local
load/store and therefore WINDOW_IN/OUT is not used.
(Normally it makes no sense to use it between
the origin and the target process because one needs an additional
synchronization. Especially a BARRIER on the RMA communicator
includes an automatic FENCE and therefore FENCE is not needed
if BARRIER is used.)
> (3) Can a FENCE even complete before the target executes a WINDOW_IN or
> WINDOW_OUT? If so, then what does it mean for a FENCE to complete?
WINDOW_IN is a local operation. The application is responsible that
it calles WINDOW_IN after after the PUT has completed at the target.
This can be made by a FENCE (called at the origin) a any additional
synchronization afterwards (e.g. a message from the origin to the
target)
The competion of a FENCE means that the data is stored at the target
"public copy".
(WINDOW_IN the means that locally on the target the content of
the public copy is "transfered" to the "privat copy" (this is
normally no copy operation, but only a cache coherence operation).)
I think that these explanations are all done in Marc's latest
text (it is alittle bit better than the officially voted one in
the last official draft).
Therefore I don't see any objective errors or lacks in the
official draft.
And I want to remember that with the official draft the application
can do its work e.g. by only calling one type of network operation,
e.g. MPI_PUT with counters at the origin.
All other stuff is made by LOCAL operations (e.g. CONSUME_COUNTER
and WINDOW_IN and local load at the target).
All other proposals are not so simple for the application,
and some seem to be more simple for the MPI implementators,
but are they really better?
> Basically, my proposal works as follows:
> MPI_PUT and MPI_GET are always non-blocking.
> MPI_PUT is matched by an MPI_ACCEPT on the target
> MPI_GET is matched by an MPI_OFFER on the target
> MPI_ACCEPT (and MPI_OFFER) take the number of MPI_PUTs (MPI_GETs) to
> match as an argument.
>
> MPI_ACCEPT and MPI_OFFER block until (1) they have matched with the
> stated number of PUTs (or GETs) on other processes, and (2) all of
> the PUTs (or GETs) preceding the ACCEPT or OFFER on the same processor
> have matched (with ACCEPTs or OFFERs in their target processes).
David, mainly MPI_ACCEPT is the same as MPI_CONSUME_COUNTER if
the counter increment in MPI_PUT is 1.
You force the use of the counter modell; therefore you loose the
FENCE modell and the BARRIER modell.
And the cache coherence operations must be inlined into MPI_ACCEPT
and MPI_OFFER.
Rolf
Rolf Rabenseifner (Computer Center )
Rechenzentrum Universitaet Stuttgart (University of Stuttgart)
Allmandring 30 Phone: ++49 711 6855530
D-70550 Stuttgart 80 FAX: ++49 711 6787626
Germany rabenseifner@rus.uni-stuttgart.de