[Mpi-22] Higher-level languages proposal

[Supalov, Alexander]

Hi,

Thanks. I'd rather say that if the purpose of the extension is indeed to
serialize the Probe/Recv pair, the better way to solve this and many
other problems would be to make threads directly addressable, as if they
were MPI processes.

One way to do this might be, say, to create a call like
MPI_Comm_thread_enroll that creates an intra-communicator out of all
threads that call this function in a loosely synchronous fashion,
collectively over one or several MPI processes they constitute.

If paired with the appropriately extended MPI_Comm_free, this would
allow, for example, all threads in an OpenMP parallel section to be
addressed as if they were fully fledged MPI processes. Note that this
would allow more than one parallel section during the program run.

Other threading models would profit from this "opt-in/opt-out" method,
too. This may be a more flexible way of dealing with threads than the
one-time MPI_Init variety mentioned by George Bosilica in his
EuroPVM/MPI keynote, by the way.

Best regards.

Alexander 

-----Original Message-----
From: mpi-22-bounces_at_[hidden]
[mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Terry Dontje
Sent: Tuesday, October 14, 2008 12:45 PM
To: MPI 2.2
Subject: 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.
>
>   

_______________________________________________
mpi-22 mailing list
mpi-22_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.