<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">I think this is simply more evidence that the shared memory access should entirely be through the valid language-specified mechanisms, including interaction with other routines and threads that may access the same memory. <div><br></div><div>I most definitely do not think that the load/store access to shared memory is intended to be associated only with memory that was somehow “allocated” by a particular process. I’m not even sure how I’d define that without referring to a particular implementation.<br><div><br></div><div>Bill</div><div><br><div><div>On Jan 22, 2015, at 2:30 AM, Rolf Rabenseifner <<a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">#1 -- The effective target rank of load/store operations is currently not<br>defined on shared memory windows. That statement may seem like nonsense. <br>However, it is important for situations where load/store operations interact<br>with RMA operations that do have an explicit target rank (e.g.<br>lock/unlock). I believe this was an oversight, and we intended that the<br>load/store operations target the rank that allocated the memory.</blockquote></blockquote></div><br></div></div></body></html>