[Mpi3-rma] Alternative Proposal for Shared Memory Support
dinan at mcs.anl.gov
Tue Mar 15 23:55:46 CDT 2011
This sounds promising, I think we should pursue it.
I initially had a question about how the allocation would be freed, but
then remembered that we've covered this already for MPI_Win_allocate
(Section 11.2.4 of the RMA proposal):
"If the window was created with MPI_WIN_ALLOCATE, MPI_WIN_FREE will free
the window memory that was allocated in MPI_WIN_ALLOCATE."
On 3/15/11 11:22 PM, Torsten Hoefler wrote:
> On Tue, Mar 15, 2011 at 09:39:24PM -0500, Rajeev Thakur wrote:
>> That's what I meant in my first mail. We need to say whether this example will work or not.
>> barrier barrier
>> x = A
>> If not, which synchronization functions need to be used and how? The
>> current text does not automatically cover this example.
> Right, I never claimed that the proposal is complete :-). It's basically
> a quick poll to see if there are major flaws and I should retract or if
> it is worth discussing at the Forum (to flesh out such things like you
> To answer your question: I think this should either be:
> barrier barrier
> This would basically insert a membar in MPI_Win_flush which makes
> sure that A is committed before the barrier completes (a barrier flag is
> set and read).
> This fits our current semantics where we suggest that win_flush can be
> used for ordering. Keep in mind that it's still the unified model, i.e.,
> the value would commit eventually, the flush is just needed to enforce
> ordering with regards to the barrier.
> Thanks& Best,
More information about the mpiwg-rma