On Sep 9, 2004, at 12:54 PM, Jaroslaw Zola wrote:
> Working on my project I run into following problem.
> In general I have two threads per one node. Here, node means one host
> with one MPI process. Both threads perform blocking send and blocking
> receive. Important is that one of them spends most of the time making
> receive. I plan to write kind of wrappers for standard MPI_Send and
> MPI_Recv - mtMPI_Send and mtMPI_Recv, respectively. mtMPI_Send locks
> global mutex, than performs MPI_Send and unlocks mutex:
>
> mtMPI_Send(...) {
> ~ LOCK_MTX
> ~ MPI_Send(...);
> ~ UNLOCK_MTX
> }
>
> The idea of mtMPI_Recv is to perform nonblocking probe, than receive:
>
> mtMPI_Send(...) {
> ~ while (flag) {
> ~ LOCK_MTX
> ~ MPI_Iprobe(..., flag)
> ~ UNLOCK_MTX
> ~ }
> ~ LOCK_MTX
> ~ MPI_Recv(...)
> ~ UNLOCK_MTX
> }
>
> Of course this approach is not really efficient, but it provides some
> kind of concurrency. What is the chance it will work with LAM?
That should actually work fine, but as you pointed out, it'll perform
fairly poorly if you have fewer CPUs than threads.
Is there a reason you have to use blocking communication and probe?
Probe is actually fairly evil. Can you use non-blocking communication
instead? Note that a blocking MPI_SEND does not necessarily imply that
the message has been received when it returns (in fact, it doesn't
indicate anything at all about the state of the receive when MPI_SEND
returns).
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
