On Jan 10, 2014, at 15:31 , Jeff Squyres (jsquyres) <jsquy...@cisco.com> wrote:
> On Jan 10, 2014, at 9:19 AM, George Bosilca <bosi...@icl.utk.edu> wrote: > >> However, one should keep in mind that MPI_Comm_free does not have to be a >> collective function, thus making any type of collective >> assumption/communications inside the attribute destructor might lead to >> deadlocks in future versions. > > Actually, MPI-3 defines MPI_COMM_FREE as collective (p248:23). As I said, this is the case today. There are ongoing discussion in the MPI Forum to relax the wording of the MPI_Comm_free as most of the MPI implementations do not rely on the strict “collective” behavior of the MPI_Comm_free (in the sense that it has to be called by all processes but not necessarily in same time). >> In other words if the only thing you do in the attribute descriptor is >> tearing down locally posted requests, then you are safe. If you send data >> using the communicator then you’re definitively playing dangerously with the >> safety line. > > I still agree with this point, though — even though COMM_FREE is collective, > you could still get into ordering / deadlock issues if you're (effectively) > doing communication inside it. As long as the call is collective and the same attributes exists on all communicators I don’t see how the deadlock is possible. My wording was more a precaution for the future than a restriction for today. George. > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
