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> 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 > > _______________________________________________ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users > -- http://www.codeproject.com/script/Articles/MemberArticles.aspx?amid=3489381
