[Mpi3-rma] RMA chapter for quick review

Bronis R. de Supinski bronis at llnl.gov
Fri Mar 11 11:43:56 CST 2011


Rajeev:

Re:
> An updated version of the RMA chapter is attached to this mail and on 
> the wiki. We would like to make it available to the Forum by tomorrow 
> afternoon in order to meet the two-week window for the first reading at 
> the March meeting. If you have a chance, please take a look at it and 
> let us know your comments before tomorrow afternoon.

I went through section 11.1 and found ticket 0 type changes.
I don't know when I will have time to finish so if I hit
something more significant I will just have to apologize.

Anyway, using [p#, l#] notation:

[1, 20]: fix split infinitive: to access or update => to access or to update

[1, 21-23]: I would like to remove the personification of the
processes in "However, processes may not know which data in their own 
memory need to be accessed or updated by remote processes, and may not 
even know the identity of these processes." Processes do not "know";
however, I have not thought of good alternative wording yet. Perhaps:
"However, a process may not necessarily be able to compute what data
in its local memory that remote processes need to access or even the
identity of those processes."

[1, 26]: Clarify antecedent: This may => This distribution may

[1, 27]: Fix split infinitives and dangling preposition:

to periodically poll for potential communication requests to receive and 
act upon. =>

to poll for potential communication requests to receive and upon which 
to act periodically.


[1, 35-38]: In the list: "MPI_PUT (remote write), MPI_GET (remote read), 
[and] MPI_ACCUMULATE (remote update), MPI_GET_ACCUMULATE, MPI_FETCH_AND_OP
(remote read and update), MPI_COMPARE_AND_SWAP (remote atomic swap 
operations), MPI_RPUT, MPI_RGET, MPI_RACCUMULATE and MPI_RGET_ACCUMULATE";
it is odd that a subset of the operations have parenthetical expressions
that indicate the nature of the functionality. Either all operations
should be followed with a parenthetical explanation or none of them.
The right solution is probably to reformat into a list with each
item being the group of operations that provide functionality of the
same nature (e.g., I am guessing that MPI_GET and MPI_RGET are both
remote read operations). Initially I thought the ones that are not
followed by a parenthetical expression were being grouped with the
following one that has the parenthetical expression (so MPI_GET_ACCUMULATE
is a remote read and update operation). However, the list ends with
several operations with no following parenthetical expression. Anyway,
the implicit grouping is unclear. Making it explicit would be better.
It would also simplify how the following sentence ("When a reference is 
made to “accumulate” operations in this chapter, it refers to the 
following operations: MPI_ACCUMULATE, MPI_GET_ACCUMULATE, MPI_FETCH_AND_OP,
MPI_COMPARE_AND_SWAP, MPI_RACCUMULATE and MPI_RGET_ACCUMULATE.") simpler.

[1, 44-45] Use active voice: correct ordering of memory accesses has to
be imposed by the user, using synchronization calls; => the user must
impose correct ordering of memory accesses through synchronization calls;

[2, 8] Change: "operations, communication coprocessors, etc." to
"operations, and communication coprocessors." The clause begins
with "such as" so the "etc." is redundant (not to mention caused
the omission of the period that should end the sentence).

[2, 12] Use active voice: "However, support for asynchronous communication
agents in software (handlers, threads, etc.) might be needed, for certain
RMA functions, in a distributed memory environment." => "However, certain
RMA functions might need support for asynchronous communication agents in
software (handlers, threads, etc.) in a distributed memory environment."


Bronis














> In particular:
> - We fixed some issues with the rules on pg 47 and 48. Please take a look at those rules in their entirety.
> - pg 3, ln 43, has been updated to specify that default value for the accumulate_ops key is same_op_no_op.
>
> Thanks,
> Rajeev
>
>


More information about the mpiwg-rma mailing list