[Mpi-22] [Mpi-forum] MPI 2.2 proposal: resolving MPI_Request_free issues

[Richard Treumann]

Sorry - the discussion is in the context of MPI_REQUEST_FREE.

MPI_ISEND(question_buffer .....    request)
MPI_REQUEST_FREE(request)
MPI_RECV( reply_buffer)
free(question_buffer)

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

Dick Treumann  -  MPI Team/TCEM
IBM Systems & Technology Group
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846         Fax (845) 433-8363

mpi-22-bounces_at_[hidden] wrote on 07/17/2008 03:11:30 PM:

> On Thu, Jul 17, 2008 at 02:51:10PM -0400, Richard Treumann wrote:
>
> > Also, in most systems support for malloc/free, the free() call does not
> > change the ability of the adapter or VMM to modify the status of the
> > address range.  The address range that had been exposed to application
use
> > before the free() is simply added back to the heap and stays there
until
> > another malloc needs it.
>
> glibc issues individual mmap()s for large allocations. These are
> returned to the OS on free. Also, if the top of the heap of small
> allocations is all free (rare due to fragmentation), it will sbrk
> backwards. Adaptors which have to maintain virt->phys mappings all
> struggle with this, in one way or another.
>
> I'm finding this whole discussion confusing. On all of the
> interconnects that I'm familiar with, freeing and modifying the buffer
> are both unsafe before the wait, and safe after. There's no free
> lunch.  Am I not thinking of some important example?
>
> -- greg
>
>
> _______________________________________________
> mpi-22 mailing list
> mpi-22_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22





* 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-22/attachments/20080717/9ad0d058/attachment.html>