Hi Robin,
Thanks a lot for your help.
I do not have to use one-sided communication.
I am open to any solution as long as it does
what I wanted. It just seems that one-sided
communication fits my need to some degree.
Having p2 and p3 both call an MPI_Recv()
or MPI_Irecv() would in effect require
the target to make a broadcast to the
rest of the world to quit receiving, which
seems to be more expensive than needed.
The example I used is overly simplified.
In real life, the rest of the world (p2
and p3) could be all busy doing some useful work.
Asking them to busy wait, even if the
time period between checks can be set
to increase exponentially after each
failure, seems to be more expensive than
needed too. And the application code
could be made complicated this way as well.
It seems to me that if p2 and p3 can do
non-busy waiting on a put() from p1, and
upon a successful put() only the target
processor is awaken, then my application
can be implemented efficiently and cleanly.
Any further suggestions are more than welcome.
Thanks,
-Lei mailto:pan_at_[hidden]
Wednesday, March 10, 2004, 12:56:23 PM, you wrote:
RH> On Tue, Mar 09, 2004 at 12:01:13AM -0800, Lei_at_ICS wrote:
>>I have three processors p1, p2, and p3.
>>On p1 there is a large array A[10000]
>>that needs to be sent to p2 or p3 depending
>>on a parameter X which is computed on
>>p1. X is not available initially on p2 or p3.
>>
>>if(X < 0.5)
>> put A[10000] to p2;
>>else
>> put A[10000] to p3;
RH> p2,p3 could just be sitting in an MPI_Recv waiting for comms from the
RH> root process.
RH> When they get a message they do the work (presumably send a result
RH> back), then get loop back to the MPI_Recv again and wait for the next
RH> work unit.
RH> You can have a zero-length message (or something else special) to tell
RH> the worker processes that they should quit.
RH> I don't see why you need one-sided comms for this problem. Did I miss
RH> something?
RH> Make it an MPI_Irecv and check it periodically if you'd prefer.
RH> The worker nodes can then be doing something else in the mean time.
RH> cheers,
RH> robin
RH> _______________________________________________
RH> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
|
