On Nov 12, 2004, at 10:55 AM, Ryan Davies wrote:
> I know that there are dire warnings against the use of LAM library
> calls in
> multiple concurrent threads. However, I was wondering if it is at all
> possible to implement threads such that one thread is constantly
> posting
> Irecv and Waitany, and another posts the occasional Send.
>
> I am trying to improve the traditional Manager/Worker model to include
> distributed dynamic load balancing. Of course, for the system to be
> properly "distributed", each worker process needs to listen for
> arbitrary
> incoming requests from its peers and act on such requests immediately.
> In
> my mind, threads would be ideal for this solution. Am I on the wrong
> track?
> Are there any resources relevant to this problem that I should know
> about?
With the LAM 7 series (both 7.0.x and 7.1.x), it is perfectly safe to
use threads with MPI. LAM only supports up to MPI_THREAD_SERIALIZED,
but supports that quite well (see the MPI-2 standard for a long
description of what all that means). Basically, you can have as many
threads calling MPI calls as you want. However, LAM is going to
serialize all those calls internally. So if you had multiple blocking
communication calls running in different threads, you would have to
think about the extra level of deadlock.
In your case, it sounds like you would hit this deadlock situation.
The Waitany() call is blocking and going to lock the LAM library. The
send is going to try to enter the LAM library and block until the
Waitany() returns. And that probably isn't what you want. With
MPI_THREAD_SERIALIZED, you can think about behavior by assuming there
is a giant mutex that is locked as soon as you enter any function
starting with MPI_ and unlocked right before exit. Good way to think
about it because it's basically what happens (with exceptions for some
of the local-only functions).
Hope this helps,
Brian
--
Brian Barrett
LAM/MPI developer and all around nice guy
Have an LAM/MPI day: http://www.lam-mpi.org/
|
