[Mpi3-rma] Alternative Proposal for Shared Memory Support

[James Dinan]

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."

Best,
  ~Jim.

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
>