Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] Unexpected behavior: MPI_Comm_accept, MPI_Comm_connect, and MPI_THREAD_MULTIPLE
From: Damien Kick (dkick_at_[hidden])
Date: 2013-05-14 16:14:33

On May 14, 2013, at 3:02 PM, Ralph Castain <rhc_at_[hidden]>

> On May 14, 2013, at 12:56 PM, Damien Kick <dkick_at_[hidden]> wrote:
>> On May 14, 2013, at 1:46 PM, Ralph Castain <rhc_at_[hidden]>
>> wrote:
>>> Problem is that comm_accept isn't thread safe in 1.6 series - we have a devel branch that might solve it, but is still under evaluation
>> So then probably the only way to implement an MPI server which handles multiple concurrent clients with Open MPI 1.6.4 is to use multiple processes to handle each client connection, yes?
> Or introduce your own thread protection around the comm_accept call

Hmm … but won't that cause other problems when the call to MPI_Comm_accept blocks while we're still holding the mutex? There doesn't seem to be an option to MPI_Comm_accept to timeout nor does there seem to be a variant of MPI_Probe to allow for a non-blocking accept. Am I missing something? One more question, too (and thanks for all your help), I don't see anything in the man page for MPI_Comm_accept which mentions iterations with signals. Is there a reliable behavior in this context, i.e. return an error from MPI_Comm_accept and set errno to EINTR? Would the C++ binding throw an exception?

<pause/> I suppose that one could use MPI_Comm_join to have "normal socket code" handle connections without worrying about blocking the rest of MPI and then only introduce a mutex when we know we're reading to MPI_Comm_join.


This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents.