tags:

views:

50

answers:

1

Hi,

Now I plan to use MPI to build a solver that supports asynchronous communication. The basic idea is as follows.

Assume there are two parallel processes. Process 1 wants to send good solutions it finds periodically to process 2. and ask for good solutions from process 2 when it needs diversification. My questions is

  1. At some point, Process 1 use MPI_send to send a solution to process2, how to guarantee there is a MPI_Rev matching this MPI_Send since this send is trigered dynamically.?

  2. When process 1 needs a solution, how can it send a request to process 2 and process 2 will notice its request in time?

Thanks for the help.

A: 

Depending on the nature of the MPI_* function you call, the send will block until a matching receive has been called by another process, so you need to make sure that's going to happen in your code. There are also non-blocking function calls MPI_Isend f.ex, which gives you a request-handle which you can check on later to see if the process' send has been received by a matching receive.

Regarding your issue, you could issue a non-blocking receive (MPI_Irecv being the most basic) and check on the status every n seconds depending on your application. The status will then be set to complete when a message has been received and is ready to be read.

If it's time sensitive, use a blocking call while waiting for a message. The blocking mechanism (in OpenMPI at least) uses a spinning poll however, so the waiting process will be eating 100% cpu.

Alexander Sagen
Thanks for your advice. In fact, I am more concerned on how the receiving process can detect there is a message coming? Using a while loop to check all the time? Is there better way?
Jackie
np :) Yeah, using the simplest paradigm of single send to single receive, you either set up an asynchronous receive which you're responsible for checking, or use a blocking call which will return immediately when there's a new message. When blocking, OpenMPI only does busy wait (eating 100% CPU while blocking for optimal communication performance) but MPICH2 can be configured to block and wait for interrupt, going easier on CPU.
Alexander Sagen