[mpiwg-rma] [EXTERNAL] Re: Synchronization on shared memory windows

Jeff Hammond jeff.science at gmail.com
Wed Feb 5 12:25:19 CST 2014


On Wed, Feb 5, 2014 at 12:14 PM, Balaji, Pavan <balaji at anl.gov> 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 <jeff.science at gmail.com> wrote:
> On Wed, Feb 5, 2014 at 11:57 AM, Balaji, Pavan <balaji at anl.gov> wrote:
>>
>> On Feb 5, 2014, at 11:54 AM, Jeff Hammond <jeff.science at gmail.com> 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
jeff.science at gmail.com



More information about the mpiwg-rma mailing list