[Mpi3-rma] RMA chapter for quick review

[William Gropp]

On Mar 11, 2011, at 11:43 AM, Bronis R. de Supinski wrote:

>
> 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
Done
>
> [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."

This really refers to the programmer, so I've proposed an alternative:

However, the
programmer may not be able to easily determine which data in a process
may need to be accessed or to be updated by operations executed by a
different process, and may not even know which processes may perform
such updates.

>
> [1, 26]: Clarify antecedent: This may => This distribution may
Done
>
> [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.
Torsten already fixed
>
>
> [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;

Done by Torsten
>
> [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).

Done
>
> [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."
>
>
Done

> 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
>>
> <ATT00001.txt>

William Gropp
Deputy Director for Research
Institute for Advanced Computing Applications and Technologies
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign