On Mon, 28 Jun 2004 hye_at_[hidden] wrote:
> 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.
Not really (I assume you mean to send *all* messages with a single tag and
just embed your own messages in there). Just think of it as using MPI to
effect your own wire-line protocol -- instead of having MPI do the
switching on the tag for you, you have to do the switching on your own
internal message structure.
> 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()?
This is the problem. There are three cases for the "count" parameter:
1. Receiver specifies a smaller number than the sender specified. This is
a truncation error, and LAM will kick off the default error handler.
Don't do this.
2. Receiver specifies the same number as the sender. This is clearly a
good thing. :-)
3. Receiver specifies a larger number than the sender. This is permitted
by the MPI standard -- LAM will simply fill in as many bytes as the sender
sent and leave the rest uninitialized.
The point here is that if you know an upper bound for the size of your
messages, you can post a "too large" receive and then use the status to
find out how many items you actually received. This scheme only works,
however, if the layout and datatypes of your messages are all the same.
If they're not, then perhaps you need to have a second "channel" -- send
an announcement message (of a fixed size and format) to a unique tag that
specifies the tag (and possibly communicator, if you are using multiple
communicators) and length of an incoming message. So you have an
"announcement" channel that receives -- in order -- a list of incoming
messages of various communicators/tags. Once you get an announcement, you
can go do the receive for the real message.
This, of course, costs a little in performance (you have to send an extra
short message for every real message that you send), but depending on your
application, it may or may not matter.
Hope this helps.
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
