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]> 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 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
> users mailing list