[mpiwg-hybridpm] mpiwg-hybridpm Digest, Vol 69, Issue 1

[Halim Amer]

All,

I have pushed my changes to pages 401-500. There are some instances that 
were not clear whether they required the change, so I am providing some 
notes below in addition to other questions. We could discuss this during 
today's meeting.

0. Shall we update the figures to reflect the change? We are the 
original raw figures?

1. I think “processes” is a generic term and should be left as it is in:
   P435: “We assume that systems have a public memory region that is 
addressable by all processes.”
   P436: “This communication paradigm is closest to a shared memory 
model, where shared data can be accessed by all processes, irrespective 
of location.”

2. In this sentence, the coarse-grained locks refer to the MPI window 
locks, right? I left it as it is, but it might have to change into “MPI 
window locks”
   P439: “RMA does not define fine-grained mutexes in memory (only 
logical coarse-grained process locks)”

3. Several instances of the expression “process memory” in the semantics 
and correctness section were not preceded by origin, target, or other 
terms that define them (P453~). When prefixing the expression with 
“MPI”, the expression does not read well. I added “an” to identify an 
arbitrary MPI process, which seems correct in those contexts, but I 
think it needs to be reviewed carefully.

4. I think multi-process can be left as it is in (P458):
“In the RMA unified model, although the public and private copies
of the windows are synchronized, caution must be used when
combining load/stores and multi-process synchronization.”
I am not sure if it makes sense to change it into multi-endpoint later 
though.

5. I changed in several examples “Process A/B/0/1” into “MPI process 
A/B/0/1”, though am not sure it is necessary.

6. I think it is better to add the term MPI here, but we might consider 
removing the term thread because it is superfluous (P479):
“A call to MPI_GREQUEST_COMPLETE may unblock a blocked user process/thread.”

7. Are we supposed to use MPI or \MPI? The threading-interface section 
already uses \MPI process all over the place

Regards,
--Halim

www.mcs.anl.gov/~aamer

On 2/6/16 11:00 AM, mpiwg-hybridpm-request at lists.mpi-forum.org wrote:
> Send mpiwg-hybridpm mailing list submissions to
> 	mpiwg-hybridpm at lists.mpi-forum.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm
> or, via email, send a message with subject or body 'help' to
> 	mpiwg-hybridpm-request at lists.mpi-forum.org
>
> You can reach the person managing the list at
> 	mpiwg-hybridpm-owner at lists.mpi-forum.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of mpiwg-hybridpm digest..."
>
>
> Today's Topics:
>
>     1. Clarification of word 'process' (Daniel Holmes)
>     2. Re: Clarification of word 'process' (Jeff Hammond)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 5 Feb 2016 19:31:55 +0000
> From: Daniel Holmes <dholmes at epcc.ed.ac.uk>
> To: Hybrid WG <mpiwg-hybridpm at lists.mpi-forum.org>
> Subject: [mpiwg-hybridpm] Clarification of word 'process'
> Message-ID: <56B4F8AB.7000508 at epcc.ed.ac.uk>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi all,
>
> I have just pushed a new branch into our mpiwg-hybrid git repo called
> "hybrid-process-clarification".
> It contains one commit: "Clarification of word 'process', pages 101-200".
> I am anticipating that each person's changes can be recorded as a commit
> with a similar message to aid identification.
>
> There are a few instances that need discussion - specifically, when the
> new MPI_AINT arithmetic functions are talking about the scope of
> validity for the resulting addresses should that be OS process or MPI
> process?
>
> Cheers,
> Dan.
>