I don't see why it matters which process allocated the memory. These are synchronization operations we are talking about and the notion of synchronization on the memory in a shared memory window should be valid in all the synchronization modes we have specified. I think it's reasonable for Rolf to want PSCW to make sense for shared memory windows. Imagine there is hardware with a point-to-point memory fence between processes (some of the new instructions in AArch64 have this feel to them, btw). And it is absolutely clear in MPI-3 that shared memory is associated with a particular process. See the rank argument in http://www.mpich.org/static/docs/v3.1/www3/MPI_Win_shared_query.html. This function takes process rank as an _input_, which means that there is a well-defined notion of memory associated with a particular process. Jeff On Sun, Jan 25, 2015 at 11:19 AM, William Gropp <[email protected]> wrote:
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.
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.
Bill
On Jan 22, 2015, at 2:30 AM, Rolf Rabenseifner <[email protected]> wrote:
#1 -- The effective target rank of load/store operations is currently not defined on shared memory windows. That statement may seem like nonsense. However, it is important for situations where load/store operations interact with RMA operations that do have an explicit target rank (e.g. lock/unlock). I believe this was an oversight, and we intended that the load/store operations target the rank that allocated the memory.
_______________________________________________ mpiwg-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
-- Jeff Hammond [email protected] http://jeffhammond.github.io/
participants (1)
-
Jeff Hammond