At each iteration, each process chooses one other process to send to
(based on the line it has just read from a file). If we send the
number of packets to expect in advance, we then need to send an
`expect zero packets from me' message to all the processes that we
don't have a message for, because this method depends on every process
knowing exactly how many messages to expect from every other process
at each iteration.
Prasadcse Perera wrote:
> I think its a real good way to use MPI_Irecv/MPI_Test on the receiver
> side to avoid any blocks which sender might run in to. But I'm a bit
> curious on the fact, Can't we use a special message beforehand between
> the sender/receivers to let the receivers know how many messages to
> expect ? This way the sender and the receiver can safely loop through
> without blocking I believe. Also even with the MPI_Irecv/MPI_Test it
> will serve as an extra proof for the receivers to proceed. Any ideas on
> that ?
> On Wed, Jul 15, 2009 at 2:15 AM, Eugene Loh <Eugene.Loh_at_[hidden]
> <mailto:Eugene.Loh_at_[hidden]>> wrote:
> Shaun Jackman wrote:
> For my MPI application, each process reads a file and for each
> line sends a message (MPI_Send) to one of the other processes
> determined by the contents of that line. Each process posts a
> single MPI_Irecv and uses MPI_Request_get_status to test for a
> received message. If a message has been received, it processes
> the message and posts a new MPI_Irecv. I believe this situation
> is not safe and prone to deadlock since MPI_Send may block. The
> receiver would need to post as many MPI_Irecv as messages it
> expects to receive, but it does not know in advance how many
> messages to expect from the other processes. How is this
> situation usually handled in an MPI appliation where the number
> of messages to receive is unknown?
> In a non-MPI network program I would create one thread for
> receiving and processing, and one thread for transmitting. Is
> threading a good solution? Is there a simpler solution?
> Under what conditions will MPI_Send block and under what
> conditions will it definitely not block?
> I haven't seen any other responses, so I'll try.
> The conditions under which MPI_Send will block are implementation
> dependent. Even for a particular implementation, the conditions may
> be tricky to describe -- e.g., what interconnect is being used to
> reach the peer, is there any congestion, etc. I guess you could use
> buffered sends... or maybe you can't if you really don't know how
> many messages will be sent.
> Let's just assume they'll block.
> I'm unsure what overall design you're suggesting, so I'll suggest
> Each process posts an MPI_Irecv to listen for in-coming messages.
> Each process enters a loop in which it reads its file and sends out
> messages. Within this loop, you also loop on MPI_Test to see if any
> message has arrived. If so, process it, post another MPI_Irecv(),
> and keep polling. (I'd use MPI_Test rather than
> MPI_Request_get_status since you'll have to call something like
> MPI_Test anyhow to complete the receive.)
> Once you've posted all your sends, send out a special message to
> indicate you're finished. I'm thinking of some sort of tree
> fan-in/fan-out barrier so that everyone will know when everyone is
> Keep polling on MPI_Test, processing further receives or advancing
> your fan-in/fan-out barrier.
> So, the key ingredients are:
> *) keep polling on MPI_Test and reposting MPI_Irecv calls to drain
> in-coming messages while you're still in your "send" phase
> *) have another mechanism for processes to notify one another when
> they've finished their send phases