Re: [Mpi-22] Higher-level languages proposal
Supalov, Alexander wrote:
Dear Jeff,
Unfortunately, I won't be in Chicago, so we should rather discuss this here. I talked to Torsten last time about this extension. As far as I can remember, the main purpose of this extension is to make sure that the thread that called the MPI_Probe also calls the MPI_Recv and gets the message matched by the aforementioned MPI_Probe.
If so, the main problem here is not the matching. The main problem is that one cannot address threads in MPI. If we fix that, the proposed extension with the message handle and such will become superfluous.
See what I mean?
Interesting, so you are basically redefining the MPI_Probe/Recv pair to guarrantee a message to go to a specific thread. Or in other words lowering the proposal's MPI_Mprobe/recv to be in the implementation of MPI_Probe/Recv. This seems reasonable to me since MPI_Probe/Recv itself is basically useless unless the programmer assures serialization when that combination is used. --td
Best regards.
Alexander
-----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Monday, October 13, 2008 11:48 PM To: MPI 2.2 Subject: Re: [Mpi-22] Higher-level languages proposal
On Oct 13, 2008, at 10:46 AM, Supalov, Alexander wrote:
Thanks. The 2.1.1, which was presented last time, in my opinion does not seem to solve the right problem. Instead of defining a way for unambiguous addressing of the threads in MPI, which would eliminate the MPI_Probe/Recv ambiguity and many other issues, it attempts to add yet another concept (this time, a message id) in the current situation where any thread can do what they please.
I'm not quite sure I understand your proposal.
<... after typing out a lengthy/rambling discourse that made very little sense and was fraught with questions and ambiguities :-) ...>
Let's discuss this in Chicago; Rich has allocated 5-7pm on Monday for discussion of this proposal. These are exactly the kinds of larger issues that we want to raise via this proposal.
participants (1)
-
unknown@example.com