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
*