1) Is a put an access, or ONLY an update? The definitions on page 107, line 29
thru 32 appear to imply that a put is NOT an access.
If the above is true, then the rules on page 108, do not appear to disallow
two concurrent puts to the same location in the same window. Is this intended?
I assume what we really mean is that a load, store, get, put and accumulate
are all "accesses". And that store, put and accumulate are all "updates".
2) We do not define when an update to local memory becomes "visible" in local
memory. I assume the implicit rule is that the the update is "immediately"
visible.
Similarly, we do not define when an update to a window copy becomes visible in
the window copy. I assume the implicit rule is that the update is visible
after the RMA operation is completed.
Assumption a) above is required to understand rule 1 on page 108 if the access
and update are both local. Assumption b) above is required to understand rule
2 on page 108 if the access and the update are both RMA.
3) The advice to users rules (page 109) are insufficient as they do not
address the problem of overlapping windows. A sufficient (but not neccessary)
rule would be to avoid overlapping windows.
4) I suggest we use the terms "public copy"/"private copy" instead of "process
memory"/"window copy" throughout the text. This abstracts the whole definition
away from the details of implementation. To be consistent with the text in
5.6, figure 5.5 should be relabeled with "public copy"/"private copy" instead
of "window copy"/"process memory". Note: a store may not update "process
memory", since the machine may have a write back cache. On such a machine the
private copy is really a combination of "process memory" and local cache.
5) In rule 2 (page 108), I assume the conflicting update may either be in this
window, or another overlapping window. The access is precluded until the
update is visible in the window copy of the updating window (we have no rule
about when an update in an overlapping window becomes visible in this window).
Similarly in rule 3, I assume line 35 should read: "...until the second update
becomes visible in the (overlapping) window copy."
6) Rule 1 on page 107 (line 36) should read: "An RMA operation is completed at
the origin by the ensuing call...". The current text mentions "process memory"
which might be confused with the target private copy. What we really mean is
the origin caller memory.
7) Rules 1 thru 3 on page 108 should use the word "should not" instead of
"cannot". The program "can" do what ever it wants, but to avoid being
erroneous, it "should" obey certain rules. The use of the word "cannot" might
imply that the implementation blocks the conflicting call until the rules are
satisfied.
8) Page 110, line 19-20: In MPI-1, the critical semantics defining
non-blocking calls is that they are local, i.e., they return without waiting
for the action of some other processor. The issue of on-going use of the local
buffer is a detail.
We should thus define post, complete, unlock, put, get and accumulate
similarly. Wait, complete, lock and barrier are clearly non-local, and
therefore blocking.
The rules for one-side are actually rather different than for point-to-point.
Consider the following:
MPI_Isend ()
MPI_Recv ()
No further MPI calls
The standard makes it clear that the receive will be completed even if the
send is never completed (non-blocking progress rule, page 44). I.e., the
enabled communication (the send) occurs.
One sided is different. An enabled put may never do anything useful until the
synchronizing operation (unlock, complete or barrier). It is entirely legal to
defer one sided operations to the complete. In contrast it is NOT legal to
defer a non-blocking send or recv until the wait.
It would appear that the progress rule for pt2pt is similar to the post/start,
complete/wait calls progress requirements. The progress issue for
put/get/complete is different. Since these are local operations, no remote
activity should be required. In particular, the following must complete:
Post
No further MPI calls Start
Get
Complete
or
Post
No further MPI calls Start
100000 puts
Complete
Progress here is local only, it doesn't involve the remote processor (and is
therefore very different than the pt2pt progress requirements).
Lloyd Lewins
Hughes Aircraft Co.,
llewins@msmail4.hac.com