(8) 13-14:
increments of one may also be more efficient than larger ones.
(instead of "small incrementsmay also be more efficient")
(10) 33 and 36-38:
Yes, I agree, that the condition
"and after the target counter has been updated"
should be deleted.
(21) 19 and 20 (IMPORTANT!!!)
On both lines you must write:
may not become automatically visible (instead of "does not ...")
(or in correct English, that the implementation can decide whether
the values become automatically visible or not.)
(22) Fig. 4.1
Please can you add the text "WINDOW_IN" and "WINDOW_OUT"
to the arrows in the Figure 4.1.
(22) 21:
Wrong reference. Fig. 4.1 instead of 4.7.3
(22) 24:
There is never a reference to Fig. 4.2.
Possibly here you can do it.
(23) Fig. 4.2:
Public (instead of External)
Privat (instead of Internal)
(24) 2: This can be achieved ... (instead of "The .....")
(24) 19: by the put if (instead of "by the store if")
(24) 28: a barrier synchronization on the RMA communicator.
=======================
(barriers on other communicators are not enough!!!)
(27) 39:
I think there should be references, where these operations
are defined, e.g.
"(This operations are defined in MPI_IACCUMULATE and MPI_REDUCE)"
(28) 18: synchronizer (instead of "targetvar")
(28) 44:
If we support BAND then we should also support BOR,
because BAND and BOR allow bitwise unlock and lock operations.
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