Re: MPI_COMM_DISCONNECT()

Raja Daoud (raja@tbag.rsn.hp.com)
Fri, 21 Jun 1996 0:40:07 CDT

> However, when the free is called, it is very easy for MPI to know that there
> are no further communications in progress. So, the process can go ahead and

> It doesn't have to know what the previous call was, it simply needs to keep
> track of the current number of outstanding communications.

Let me make Eric's statement even stronger: MPI-1 already _has_ to keep
track of the # of outstanding communication requests per communicator,
in order to handle MPI_Comm_free() [and MPI_Finalize()] correctly. This
functionality is embedded in correct MPI-1 implementations. Now we are
finding that it needs to be exported to the user to cleanly handle the
client/server detaching step.

> I think that we can define "before" and "after" in strictly local terms. The

As an example, we are currently doing that with MPI_Fence() for 1-sided
communication.

By making it non-collective, clients who have finished communicating
aren't mandated to block waiting for the few processes that are lagging
behind. I see no need to force the equivalent of a barrier before
detaching.

--Raja

-=-
Raja Daoud Hewlett-Packard Co.
raja@rsn.hp.com Convex Division