On Wed, Feb 5, 2014 at 12:14 PM, Balaji, Pavan <[email protected]> wrote:

OK, I thought you were referring to a generic memory barrier call, not related to the window.

In what case will you need this call outside the epoch, given that you can only access the window content in an epoch?

On Feb 5, 2014 12:06 PM, Jeff Hammond <[email protected]> wrote: On Wed, Feb 5, 2014 at 11:57 AM, Balaji, Pavan <[email protected]> wrote:

...

On Feb 5, 2014, at 11:54 AM, Jeff Hammond <[email protected]> wrote:

...

I think advice to users regarding WIN_SYNC wouldn't hurt given that some of us are talking about it as if it is a portable abstraction for a memory barrier when it is now only correct to use it within an RMA sync epoch. Or we need to relax this restriction.

Without this restriction, there’s no connection to what memory is being made consistent with the WIN_SYNC call. I’d be against removing it.

The memory being made consistent is obviously the public and private window. In the case of UNIFIED, it's just a memory barrier. Right?

I suppose someone could always WIN_LOCK+WIN_SYNC+WIN_UNLOCK as a portable abstraction for a memory barrier in the case where an epoch is not already established.

Does load-store against a shared memory window have to be inside of an epoch? I can't remember but if it does, then shared memory windows are not the magic abstraction for POSIX shm that I though they were. Jeff -- Jeff Hammond [email protected]