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