Thank you, Jeff.
You really save lots of my time to centralized the problem.
Then if I want to receive messages with different TAGs in the exact order they
are sent, and the receiver doesn't know the number(maybe zero) and order of
those messages in advance, what kind of structure I should use in the
receiver's side?
The simplest solution I'm thinking of is to wrap all my messages with a UINQUE
tag, so that First-sent-First-Received can be guaranteed; but it seems
completely wasting the TAG.
As you mentioned, use MPI_Irecv()/MPI_Test(),MPI_Wait() instead of MPI_Iprobe(),
but in the environment that I don't know where the message comes from and not
sure which tag is coming or not, how can I specify the "count" parameter in the
MPI_Irecv()?
Thanks so much your kindly help.
Hua Ye
Quoting Jeff Squyres <jsquyres_at_[hidden]>:
> > The problem seems to be that some "later" messages are received prior to
> > the "previous" sent messages. Here's the structure of my code:
> >
> > Sender processors:
> > ... MPI_Isend(...)/MPI_Send(...) with various tag...
> >
> > Recver processors:
> > ...
> > MPI_Iprobe(MPI_ANY_SOURCE, MPI_ANY_TAG, MPI_COMM_WORLD, &rc,
> > &status);
> > if (rc) {
> > MPI_Recv(&msg, sizeof(msg), MPI_BYTE, status.MPI_SOURCE,
> > status.MPI_TAG, MPI_COMM_WORLD, &status1);
> > ...
> > }
>
> This code looks ok. But you might consider against using Probe and/or
> MPI_ANY_TAG -- see below.
>
> > My question is: is the First-sent-First-Received can be guaranteed? For
> > example, if one processor sends out message to other processor using
> > MPI_Isend or MPI_Send or both, in the sequence of TAG1, TAG2, TAG1,
> > TAG3, TAG2. Can it be guaranteed that, in the receiver side, the
> > sequence is still TAG1, TAG2, TAG1, TAG3, TAG2?
>
> No.
>
> MPI only guarantees that the order of messages sent with the same
> signature (i.e., sender and receiver, communicator, and tag) are ordered.
> Hence, it is possible (and legal) for MPI to allow messages with different
> tags to be delivered out of order (even with ANY_TAG).
>
> However, I recommend against using MPI_Probe and/or MPI_ANY_TAG.
>
> <shameless plug>
>
> In this month's Cluster World magazine (July 2004), I write about my Top
> 10 List of Evils to Avoid in Parallel ("In Parallel, Everyone Hears You
> Scream"). MPI_PROBE is #8; MPI_ANY_SOURCE is #3 (numbers 10-6 are this
> month; 5-1 are next month).
>
> </shameless plug>
>
> >From your code, it looks like you're attempting to not receive until the
> message has actually arrived. MPI actually gives you a better way to
> effect this kind of behavior -- use non-blocking receives. Post a few
> non-blocking receives for the messages that you're expecing and then use
> the various flavors of MPI_TEST and MPI_WAIT to know when they have
> actually been received. Indeed, using MPI_PROBE frequently causes the MPI
> implementation to perform an additional memory copy (LAM does, at least).
> This is because LAM has to receive the message into a temporary buffer and
> then when you finally post the matching MPI_RECV, LAM copies it out of the
> temporary buffer into the destination buffer.
>
> So try to avoid MPI_PROBE.
>
> MPI_ANY_SOURCE isn't as bad, but you should avoid it if you can. I'll
> skip the rationale here; using it (or not) is probably not the problem
> that you're seeing here.
>
> --
> {+} Jeff Squyres
> {+} jsquyres_at_[hidden]
> {+} http://www.lam-mpi.org/
> _______________________________________________
> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
>
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
|
