[Mpi3-hybridpm] new version of proposal

Joe Ratterman jratt0 at gmail.com
Thu Nov 12 11:27:36 CST 2009


Marc,

I had a few clarification questions that I also wanted to ask about the V3
proposal.


>From section 1.4:

> The  binding  of  threads  to  MPI  endpoints  can  change  during  program
> execution, but is explicit, and is expected to change rarely (hence need not
> be a fast operation). This choice allows  endpoint  creation  to precede
> thread  spawning;  it is  not expected  to  add significant complexity to
> the implementation.
>
What does this imply about the case of a thread that attaches to an endpoint
and then spawns a thread?  Is the new thread also attached to the same
endpoint?  This would have obvious negative issues in MPI_THREAD_FUNNELED,
and would also complicate use of thread-local-storage in the implementation
to track the selected endpoint.  My opinion would be that new threads should
be defined to be detached from endpoints.


>From section 2.2:

> ...it will generate a communicator MPI_COMM_EWORLD  that includes all
> endpoints and has num_endpoints endpoints at each calling process.
>
Upon first read, my coworkers and I are often confused by this sentence,
which seems to say that num_endpoints must be the same everywhere.  By now
I'm pretty sure that isn't the case, so I'm hoping that it can be reworded
to make that more clear.  Maybe, "...it will generate a communicator
MPI_COMM_EWORLD that includes all endpoints and is of the size of the sum of
the unique num_endpoints supplied by each calling process."


What is the mapping between the ranks of endpoints in MPI_COMM_PROCESS and
the index of the endpoint handle in the array returned from
MPI_Endpoint_create?  I would suggest that it be clearly stated that
MPI_Thread_attach(array[X]) will always result in the thread becoming rank X
in MPI_COMM_PROCESS.  It might also help to establish a fixed mapping
between WORLD, EWORLD, and PROCESS, but that seems less important.


I noticed that the example in section 5.3 uses MPI_Endpoint_register().  Is
it supposed to be MPI_Thread_attach?


Thanks,
Joe Ratterman


On Mon, Nov 9, 2009 at 10:43 PM, Snir, Marc <snir at illinois.edu> wrote:

> Is appended on the wiki. I believe (hope) that it addresses all
> comments I received on the previous version.
> I hope to post slides tomorrow.
>
>
> Marc Snir
> Michael Faiman and Saburo Muroga Professor
> Department of Computer Science, University of Illinois at Urbana
> Champaign
> 4323 Siebel Center, 201 N Goodwin, IL 61801
> Tel (217) 244 6568
> Web http://www.cs.uiuc.edu/homes/snir
>
>
>
>
>
>
> _______________________________________________
> 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/20091112/ba6d2eca/attachment-0001.html>


More information about the mpiwg-hybridpm mailing list