Hello,
What are the changes between openMPI 1.4.1 and 1.5.1 about MPI2 service
of publishing name.
I have 2 programs which connect them via MPI_Publish_name and
MPI_Lookup_name subroutines and ompi-server.
That's OK with 1.4.1 version , but I have a deadlock with 1.5.1 version
inside the subro
Is it a bug in openmpi V1.5.1 ?
Bernard
Bernard Secher - SFME/LGLS a écrit :
Hello,
What are the changes between openMPI 1.4.1 and 1.5.1 about MPI2
service of publishing name.
I have 2 programs which connect them via MPI_Publish_name and
MPI_Lookup_name subroutines and ompi-server.
That's OK
On Jan 5, 2011, at 10:36 AM, Bernard Secher - SFME/LGLS wrote:
> MPI_Comm remoteConnect(int myrank, int *srv, char *port_name, char* service)
> {
> int clt=0;
> MPI_Request request; /* requete pour communication non bloquante */
> MPI_Comm gcom;
> MPI_Status status;
> char port_name_c
Jeff,
Only the processes of the program where process 0 successed to publish
name, have srv=1 and then call MPI_Comm_accept.
The processes of the program where process 0 failed to publish name,
have srv=0 and then call MPI_Comm_connect.
That's worked like this with openmpi 1.4.1.
Is it diffe
Jeff,
The dead lock is not in MPI_Comm_accept and MPI_Comm_connect, but before
in MPI_Publish_name and MPI_Lookup_name.
So the broadcast of srv is not involved in the dead lock.
Best
Bernard
Bernard Secher - SFME/LGLS a écrit :
Jeff,
Only the processes of the program where process 0 success
I get the same dead lock with openmpi tests: pubsub, accept and connect
with version 1.5.1
Bernard Secher - SFME/LGLS a écrit :
Jeff,
The dead lock is not in MPI_Comm_accept and MPI_Comm_connect, but
before in MPI_Publish_name and MPI_Lookup_name.
So the broadcast of srv is not involved in t
The accept and connect tests are OK with version openmpi 1.4.1.
I think there is a bug in version 1.5.1
Best
Bernard
Bernard Secher - SFME/LGLS a écrit :
I get the same dead lock with openmpi tests: pubsub, accept and
connect with version 1.5.1
Bernard Secher - SFME/LGLS a écrit :
Jeff,
Th
You're calling bcast with root=0, so whatever value rank 0 has for srv,
everyone will have after the bcast. Plus, I didn't see in your code where *srv
was ever set to 0.
In my runs, rank 0 is usually the one that publishes first. Everyone then gets
the lookup properly, and then the bcast send
srv = 0 is set in my main program
I call Bcast because all the processes must call MPI_Comm_accept
(collective) or must call MPI_Comm_connect (collective)
Anyway, I get also a dead lock with your lookup program:
That's what I do:
ompi-server -r URIfile
mpirun -np 1 -ompi-server file:URIfile
On Jan 7, 2011, at 10:41 AM, Bernard Secher - SFME/LGLS wrote:
> srv = 0 is set in my main program
> I call Bcast because all the processes must call MPI_Comm_accept (collective)
> or must call MPI_Comm_connect (collective)
Ah -- I see. I thought this was a test program where some processes wer
On Jan 7, 2011, at 11:16 AM, Jeff Squyres wrote:
> Ok, I can replicate the hang in publish now. I'll file a bug report.
Filed here:
https://svn.open-mpi.org/trac/ompi/ticket/2681
Thanks for your persistence!
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http:
11 matches
Mail list logo
