On 8/27/13 12:19 PM, "Pavan Balaji" <[email protected]> wrote:

On 08/27/2013 12:57 PM, Jeff Hammond wrote:

...

The MPI standard will not define by what mechanism the SHMEM implementation will establish the necessary consistency. This is what I mean by undefined = implementation-defined. I do not think that Keith is proposing to enumerate all processor memory models and the appropriate fences required to achieve the affect of win_sync but at lower cost. Thus, it is the implementation - or perhaps more accurately, the platform on which the implementation resides - that will define these semantics.

Here's what I understood from Keith --

He wants a statement in the standard that says the application can do platform-specific memory consistency to synchronize the public and private windows in UNIFIED.

I do agree that that's a very flimsy statement and doesn't really mean much. But I'm calling it a definition, while I think you are saying that it's pretty much undefined.

I like leaving it totally undefined better than the above "definition".

I'm having trouble with the exact phrasing, but my thought is that we should have an advice to users that says 1) while the view of memory is consistent in UNIFIED, other artifacts (such as processor or memory controller reordering) can result in unexpected behavior 2) MPI_WIN_SYNC may be used to provide stronger ordering guarantees and 3) an application programmer may use other, implementation defined, semantics to provide required ordering guarantees. That is, we should say explicitly that the user can cause oddness, that MPI has a mechanism to fix that oddness, and that the user may also seek other mechanisms to solve the oddness, should she so desire. Brian -- Brian W. Barrett Scalable System Software Group Sandia National Laboratories