[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