but we had to start with a problem in RMA semantics that exists since MPI-2.0.
Rolf's mail said the problem exists since MPI-2.0, hence my reply. Rajeev On Jun 30, 2014, at 9:34 AM, "Balaji, Pavan" <[email protected]> wrote:
Rajeev,
We are not talking about RMA operations, but load/store operations. Please see the examples we mentioned in the ticket.
— Pavan
On Jun 30, 2014, at 9:25 AM, Rajeev Thakur <[email protected]> wrote:
No, the user can assume correct RMA semantics. The implementation has to decide whether it can provide those semantics with or without a barrier.
Rajev
On Jun 30, 2014, at 9:13 AM, "Balaji, Pavan" <[email protected]> wrote:
Rajeev,
We understand the “may” part and that’s the entire point of the ticket. That is, the user cannot assume that it’ll block. Hence either the examples are wrong or the wording is wrong. We believe the wording is incorrect.
— Pavan
On Jun 30, 2014, at 8:58 AM, Rajeev Thakur <[email protected]> wrote:
The ticket's premise is wrong in my opinion :-).
First of all the sentence "For post-start-complete-wait, there is no specified requirement that the post and start calls need to synchronize." is not right.
pg 442, ln 31-33: "MPI_WIN_START is allowed to block until the corresponding MPI_WIN_POST calls are executed, but is not required to."
When the standard says the first fence "may" not be a barrier or the above where start "may" not block, it means that if the implementation is able to provide the right fence or pscw semantics without a barrier or block, it may. If it cannot, then it should barrier or block or do something.
An example of where the "may" case works is where the implementation defers all RMA operations to the "second" fence or to the wait-complete. In that case, it is free not to barrier in the first fence or wait for the post.
Rajeev
On Jun 30, 2014, at 5:39 AM, Rolf Rabenseifner <[email protected]> wrote:
Marc, Bill, and Rajeev,
Marc, as far as I remember, you are the author of the 6 rules on one-sided semantics on MPI-3.0 page 453 line 39 through page 454 line 21 (in MPI-2.0 the rules were on page 138).
At ISC 2014, Pavan Balaji, Hubert Ritzdorf and I met to discuss the unclear RMA synchronization for shared memory, but we had to start with a problem in RMA semantics that exists since MPI-2.0.
The outcome was https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/434
Marc as original author, Bill and Rajeev as chapter chairs, please can you check whether we are right with this ticket:
- that the gap between the expected behavior and the current semantic rules really exists, and - that our solution is correct, - and hopefully that it is a good way of filling the gap.
Best regards Rolf
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) _______________________________________________ mpiwg-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
_______________________________________________ mpiwg-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma