[Mpi3-rma] Alternative Proposal for Shared Memory Support

James Dinan dinan at mcs.anl.gov
Tue Mar 15 23:55:46 CDT 2011

Hi Torsten,

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.
>> A=10
>> 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
> mentioned).
> To answer your question: I think this should either be:
> A=10
> MPI_Win_flush
> barrier           barrier
>                    x=A
> 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,
>    Torsten

More information about the mpiwg-rma mailing list