Hi Prasadcse,
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.
Cheers,
Shaun
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....@sun.com
<mailto:eugene....@sun.com>> 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
something.
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
finished.
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
