[Mpi3-hybridpm] Fwd: tickets 310 313 317

Marc Snir snir at mcs.anl.gov
Fri Feb 24 15:54:44 CST 2012



Begin forwarded message:

> From: Douglas Miller <dougmill at us.ibm.com>
> Subject: Re: [Mpi3-hybridpm] tickets 310 313 317
> Date: February 24, 2012 4:17:46 PM EST
> To: mpi3-hybridpm at lists.mpi-forum.org
> Reply-To: mpi3-hybridpm at lists.mpi-forum.org
> 
> Last time we discussed these, I thought there were going to be some minor changes made. Unfortunately, these revised texts seem to have significant changes, and are farther from what I was comfortable with. We don't seem to be converging on a target. Here's what I've been thinking:
> 
> * One MPI_INIT (or MPI_INIT_THREAD) and one MPI_FINALIZE per OS process. After MPI_INIT*, all MPI Processes are initialized.
> 
> 
You have this in my proposal. However, I don't prohibit one MPI_Init call per MPI process.

> * Every thread is associated with one MPI Process by default. Which MPI Process is implementation defined. A call to MPI_COMM_RANK on MPI_COMM_WORLD will tell which. (sub-communicators might return MPI_PROC_NULL)
> 
You have this in my proposal if you use MPI_THREAD_MULTIPLE

> 
> * changing associated is permitted with MPI_THREAD_ATTACH (not sure I'm comfortable with the abstract "index" version of this, I like (MPI_COMM, rank) more)
> 
> 
If we are sure we can get  in the standard the ability to migrate a thread from one MPI process to another, then your approach is fine. But, if we are not sure that this will pass, then I prefer to push for a new level of thread support. Whether threads are attached by default in this case or not is something I can go either way. With the interface I propose, threads need not be attached to any MPI process, which I think is an advantage. In an environment, such as OpenMP, with dynamic  thread support, where threads come and go, I doubt that it makes much sense to attach threads to MPI processes by default; the user will want to control which thread is attached to which MPI process.

> * No new thread levels. Specify that thread level is relative to the MPI Process. I'm OK with requiring that multiple MPI processes requires thread level > MPI_THREAD_SINGLE, although I'm not sure it is necessary.
> 


Thread level is relative to address space -- otherwise how can you have only one MPI_INIT_THREAD call per address space?

> 
> MPI_COMM_SPLIT_TYPE is fine as-is, I think.
> 
> 
> 


> 
> _______________________________________________
> Douglas Miller                  BlueGene Messaging Development
> IBM Corp., Rochester, MN USA                     Bldg 030-2 A401
> dougmill at us.ibm.com               Douglas Miller/Rochester/IBM
> 
> Marc Snir ---02/22/2012 09:12:08 AM---Marc Snir <snir at mcs.anl.gov>
> 
> Marc Snir <snir at mcs.anl.gov> 
> Sent by: mpi3-hybridpm-bounces at lists.mpi-forum.org
> 02/22/2012 09:07 AM
> Please respond to
> mpi3-hybridpm at lists.mpi-forum.org
> 
> To
> 
> mpi3-hybridpm at lists.mpi-forum.org,
> 
> cc
> 
> 
> Subject
> 
> [Mpi3-hybridpm] tickets 310 313 317
> 	
> I posted text for each of them. Text for ticket 311 is now part of text for ticket 310. Please read and comment.
> 
> 
> 
> _______________________________________________
> Mpi3-hybridpm mailing list
> Mpi3-hybridpm at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm
> 
> 
> _______________________________________________
> Mpi3-hybridpm mailing list
> Mpi3-hybridpm at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-hybridpm/attachments/20120224/77c47dec/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-hybridpm/attachments/20120224/77c47dec/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-hybridpm/attachments/20120224/77c47dec/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic25680.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-hybridpm/attachments/20120224/77c47dec/attachment-0005.gif>


More information about the mpiwg-hybridpm mailing list