<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<p dir="ltr"><br>
OK, I thought you were referring to a generic memory barrier call, not related to the window.</p>
<p dir="ltr">In what case will you need this call outside the epoch, given that you can only access the window content in an epoch?</p>
<div class="x_quote">On Feb 5, 2014 12:06 PM, Jeff Hammond <jeff.science@gmail.com> wrote:<br type="attribution">
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On Wed, Feb 5, 2014 at 11:57 AM, Balaji, Pavan <balaji@anl.gov> wrote:<br>
><br>
> On Feb 5, 2014, at 11:54 AM, Jeff Hammond <jeff.science@gmail.com> wrote:<br>
>> I think advice to users regarding WIN_SYNC wouldn't hurt given that<br>
>> some of us are talking about it as if it is a portable abstraction for<br>
>> a memory barrier when it is now only correct to use it within an RMA<br>
>> sync epoch. Or we need to relax this restriction.<br>
><br>
> 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.<br>
<br>
The memory being made consistent is obviously the public and private<br>
window. In the case of UNIFIED, it's just a memory barrier. Right?<br>
<br>
I suppose someone could always WIN_LOCK+WIN_SYNC+WIN_UNLOCK as a<br>
portable abstraction for a memory barrier in the case where an epoch<br>
is not already established.<br>
<br>
Jeff<br>
<br>
<br>
-- <br>
Jeff Hammond<br>
jeff.science@gmail.com<br>
_______________________________________________<br>
mpiwg-rma mailing list<br>
mpiwg-rma@lists.mpi-forum.org<br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a></div>
</span></font>
</body>
</html>