[mpi3-coll] array parameters in nonblocking collectives

[Graham, Richard L.]

For a period of time this will double the memory use for these arrays, so this will not change the order of magnitude of the memory requirements. If we are concerned about scalability, we should address this specifically.

Rich

________________________________
From: mpi3-coll-bounces at lists.mpi-forum.org
To: 'MPI-3 Collective Subgroup Discussions'
Sent: Sat Aug 01 11:18:41 2009
Subject: Re: [mpi3-coll] array parameters in nonblocking collectives

That means the MPI implementation would need to make a copy of potentially large lists. Reference counting won't work here. And the user could easily issue several nonblocking calls in a row. Ouch.

Rajeev


________________________________
From: mpi3-coll-bounces at lists.mpi-forum.org [mailto:mpi3-coll-bounces at lists.mpi-forum.org] On Behalf Of Graham, Richard L.
Sent: Saturday, August 01, 2009 9:57 AM
To: 'mpi3-coll at lists.mpi-forum.org'
Subject: Re: [mpi3-coll] array parameters in nonblocking collectives


I would expect that the user arguments shouild not be expected to be preserved in the user's arrays between posting the collectives and completing them.

Rich

________________________________
From: mpi3-coll-bounces at lists.mpi-forum.org
To: Torsten Hoefler
Cc: MPI-3 Collective Subgroup Discussions
Sent: Sat Aug 01 09:56:50 2009
Subject: [mpi3-coll] array parameters in nonblocking collectives

Hi,

I have one question about the array parameters (sendcounts, recvcounts,  sdispls and rdispls) in nonblocking collectives such as MPI_IALLTOALLV. Are callers allowed to modify/destroy those arrays upon the return of the calls, or they must wait until after the MPI_WAIT call?  I could not find the correct behavior defined in the latest proposal (nbc-proposal-rev-6.2.pdf) and do not remember having discussion on such.
I think this issue is quite unique to nonblocking collective communication calls since arrays in other MPI nonblocking calls are arrays of MPI objects, for which the correct handling is well defined. So it needs to be clarified.
Am I missing something?

Thanks
Bin Jia
Communication Protocol Development
Advanced Clustering Technology Team, IBM STG
Poughkeepsie, NY 12601
Tel: 845-433-6301(T/L 293-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-coll/attachments/20090801/4f6fafe1/attachment-0001.html>