<html><body>
<p>Sorry - the discussion is in the context of MPI_REQUEST_FREE.  <br>
<br>
MPI_ISEND(question_buffer .....    request)<br>
MPI_REQUEST_FREE(request)<br>
MPI_RECV( reply_buffer)<br>
free(question_buffer)<br>
<br>
Where the MPI_RECV is for a reply that will come back from the task the ISEND went to after the ISEND message is received and the completion of the send side MPI_RECV is taken as sufficient for calling free on the ISEND buffer<br>
<br>
<br>
<br>
Dick Treumann  -  MPI Team/TCEM            <br>
IBM Systems & Technology Group<br>
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846         Fax (845) 433-8363<br>
<br>
<br>
<tt>mpi-22-bounces@lists.mpi-forum.org wrote on 07/17/2008 03:11:30 PM:<br>
<br>
> On Thu, Jul 17, 2008 at 02:51:10PM -0400, Richard Treumann wrote:<br>
> <br>
> > Also, in most systems support for malloc/free, the free() call does not<br>
> > change the ability of the adapter or VMM to modify the status of the<br>
> > address range.  The address range that had been exposed to application use<br>
> > before the free() is simply added back to the heap and stays there until<br>
> > another malloc needs it.<br>
> <br>
> glibc issues individual mmap()s for large allocations. These are<br>
> returned to the OS on free. Also, if the top of the heap of small<br>
> allocations is all free (rare due to fragmentation), it will sbrk<br>
> backwards. Adaptors which have to maintain virt->phys mappings all<br>
> struggle with this, in one way or another.<br>
> <br>
> I'm finding this whole discussion confusing. On all of the<br>
> interconnects that I'm familiar with, freeing and modifying the buffer<br>
> are both unsafe before the wait, and safe after. There's no free<br>
> lunch.  Am I not thinking of some important example?<br>
> <br>
> -- greg<br>
> <br>
> <br>
> _______________________________________________<br>
> mpi-22 mailing list<br>
> mpi-22@lists.mpi-forum.org<br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</a><br>
</tt></body></html>