Marc,<br><br>I had a few clarification questions that I also wanted to ask about the V3 proposal.<br>
<br><br>From section 1.4:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 6.8ex; padding-left: 1ex;" class="gmail_quote">
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. <br>



</blockquote>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.<br>



<br><br>From section 2.2:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 6.8ex; padding-left: 1ex;" class="gmail_quote">...it will generate a communicator MPI_COMM_EWORLD  that includes all endpoints and has num_endpoints endpoints at each calling process.<br>

</blockquote>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."<br>

<br><br>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.<br>



<br><br>I noticed that the example in section 5.3 uses MPI_Endpoint_register().  Is it supposed to be MPI_Thread_attach?<br><br><br>Thanks,<br><font color="#888888">Joe Ratterman<br><br></font><br><div class="gmail_quote">


On Mon, Nov 9, 2009 at 10:43 PM, Snir, Marc <span dir="ltr"><<a href="mailto:snir@illinois.edu" target="_blank">snir@illinois.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


Is appended on the wiki. I believe (hope) that it addresses all<br>
comments I received on the previous version.<br>
I hope to post slides tomorrow.<br>
<br>
<br>
Marc Snir<br>
Michael Faiman and Saburo Muroga Professor<br>
Department of Computer Science, University of Illinois at Urbana<br>
Champaign<br>
4323 Siebel Center, 201 N Goodwin, IL 61801<br>
Tel (217) 244 6568<br>
Web <a href="http://www.cs.uiuc.edu/homes/snir" target="_blank">http://www.cs.uiuc.edu/homes/snir</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Mpi3-hybridpm mailing list<br>
<a href="mailto:Mpi3-hybridpm@lists.mpi-forum.org" target="_blank">Mpi3-hybridpm@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm</a><br>
</blockquote></div><br>