Re: [mpiwg-hybridpm] mpiwg-hybridpm Digest, Vol 69, Issue 1
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, [email protected] wrote:
Send mpiwg-hybridpm mailing list submissions to [email protected]
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 [email protected]
You can reach the person managing the list at [email protected]
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 <[email protected]> To: Hybrid WG <[email protected]> Subject: [mpiwg-hybridpm] Clarification of word 'process' Message-ID: <[email protected]> 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.
participants (1)
-
Halim Amer