X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 10 May 2001 12:55:30 -0500
To: mpi-21@XXXXXXXXXXXXX
From: William Gropp <gropp@XXXXXXXXXXX>
Subject: Re: MPI_FINALIZE
Cc: mpi-21@XXXXXXXXXXXXX,Jeff Squyres <jsquyres@XXXXXXXXXXX>
In-Reply-To: <20010510105421.C2781@XXXX>
References: <200105100849.f4A8npK08386@XXXXXXXXXXXXXXXXXXXXXXXXXX>
 <Pine.LNX.4.31.0105061721440.6963-100000@XXXXXXXXXXXXXXXXX> <200105100849.f4A8npK08386@XXXXXXXXXXXXXXXXXXXXXXXXXX>Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpi-21@XXXXXXXXXXXXX
Precedence: bulk
Reply-To: mpi-21@XXXXXXXXXXXXX

At 10:54 AM 5/10/2001 -0400, Nicholas Nevin - Sun HPC High Performance Computing wrote:

Correct handling of my most disliked feature in MPI, the cancelling of
sends, seems to require a barrier or something similar in
MPI_Finalize.

See example 3.4 in section 3.2.2 (Clarification of MPI_Finalize) of the MPI-2
standard. Pages 23-24.

I read that text as saying the opposite; see in particular examples 3.1 and 3.2 (replacing MPI_Request_free with MPI_Cancel).  Example 3.4 says only that MPI_Finalize may need to wait if there are incomplete messages that could be but have not yet been cancelled.  This example only says that it is erroneous for an implementation to complain about unreceived messages at MPI_Finalize unless it can guarantee that that unreceived message won't be cancelled by the sending process.  The "advice to implementors" suggests a sufficient but not necessary solution (use a barrier).

Bill