[MPICH] Stopping processors?
Darius Buntinas
buntinas at mcs.anl.gov
Tue Apr 24 10:47:27 CDT 2007
One idea would be to have each worker process spawn a "computation"
thread which actually does the computation. The "main" thread of the
process would issue a blocking receive waiting for a "done" message.
When a computation thread at some process finishes, it sends messages to
the other processes and to itself. When a main thread receives a done
message, it checks whether it received the message from its own
computation thread. If so, it does a pthread_join() and reads the
result, otherwise it does a pthread_cancel().
At this point the main thread can wait for a message to start the next
computation.
If you have a lot of processes having one process send a done message to
every other process isn't scalable. You could optimize in that case by
having the processes forward the message in a tree.
-d
Michaela Heyer wrote:
> Hi,
> I'm hoping someone can help me with this...
> Essentially I'm looking for a way to tell one or more processors to stop
> whatever they are currently doing and move on to something else. The
> situation is as follows: Let's say we have n processors all working on
> different algorithms. I only really need the result of one of these
> algorithms so whichever processor finishes first should tell all the other
> ones to stop so they can all move on to the next problem. It's a bit like a
> race...and speed is vital! (That's why I can't really wait for all processors
> to finish their algorithms)
> At the moment I'm using MPI_Abort() to shutdown the whole process. This works
> fine and does exactly what I need but the problem is that it is very very
> slow as it shuts down and restarts all the processors. So what I'm looking
> for is something like a "milder" version of MPI_Abort() i.e. stop everything
> but don't shutdown the processors.
> I have been looking but can't find anything sutitable so I'm starting to think
> that maybe it's impossible? It would be great if you could prove me wrong :-)
> Thanks,
> Michaela
>
More information about the mpich-discuss
mailing list