Christian Siebert wrote:
Hi Edgar,
cid's are in fact not recycled in the block algorithm. The problem is
that comm_free is not collective, so you can not make any assumptions
whether other procs have also released that communicator.
well, that's not quite correct. The MPI standard says the following
about MPI_Comm_free (MPI 2.1, p 201, l 43): "This collective operation
marks the communication object for deallocation.". So MPI_Comm_free is
collective which makes the prescribed problem(s) easier so solve.
Christian,
you are right, but unfortunately it doesn't help in this scenario.
Consider the following test case, which fulfills the MPI spec:
MPI_Comm_dup ( MPI_COMM_WORLD, &comm1 );
if ( rank == 0 ) {
MPI_Isend ( dest=1, comm1, &req );
MPI_Wait ( req, stat);
MPI_Comm_free ( comm1);
MPI_Comm_dup ( MPI_COMM_WORLD, &comm 2);
}
if ( rank == 1 ) {
MPI_Irecv ( src=0, comm1, &req );
MPI_Comm_free ( &comm1 );
MPI_Comm_dup ( MPI_COMM_WORLD, comm1 );
MPI_Wait ( &req, stat);
}
In this case, rank=0 thinks that the CID of comm1 can be reused, but
rank=1 can not reuse that CID yet, since the pending communication
operation still has to finish. If you want determine the communicator id
without communication (which is the goal of the block algorithm), you
can not do that based on your local information. Collective !=
synchronous...
Thanks
Edgar
However, I admit that there exist an advice to implementors that
anticipates a local implementation. Personally I find this advice rather
strange and (if nobody can give a good reason for it) would encourage
its removal...
Best regards,
Christian
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Edgar Gabriel
Assistant Professor
Parallel Software Technologies Lab http://pstl.cs.uh.edu
Department of Computer Science University of Houston
Philip G. Hoffman Hall, Room 524 Houston, TX-77204, USA
Tel: +1 (713) 743-3857 Fax: +1 (713) 743-3335
