[Mpi3-rma] Fix for win_allocate_shared

Torsten Hoefler htor at illinois.edu
Fri Sep 23 13:11:33 CDT 2011

On Fri, 2011-09-23 at 12:56 -0500, Pavan Balaji wrote:
> On 09/23/2011 12:47 PM, Barrett, Brian W wrote:
> > It might not be able to. If non-coherent load/store is byte access
> > (or word access), it can provide a separate public and private window
> > in separate and meet the semantics.  If it provides cacheline access
> > to non-coherent space, it will not be able to provide shared memory
> > across uncached space; such is the cost of standardization.
> Do we know any non-cache-coherent system that provides byte access (note 
> that word access is not sufficient)?
> What I'm arguing is that we are not giving any additional flexibility 
> for non-cache-coherent systems with this new "clarified semantics". In 
> fact, we are making it more difficult for future MPI versions to 
> actually define a semantics by saying that "multiple remote stores to 
> the same window have to work" -- we'll be stuck with this if we say that 
> in the standard now.
I see your point but would like to postpone to the telecon.

> Instead, if we leave it undefined, in MPI-3.1 (or 4.0), we might be able 
> to separate out local load/store and remote load/store operations and 
> say that multiple remote load/store operations is undefined (or 
> erroneous or whatever).
> So the options I'm proposing are:
> 1. Either define remote load/stores in SEPARATE.
I think we can just define that concurrent accesses are undefined.

> (or)
> 2. Leave it as undefined.
> Attempting a half-definition is making it worse than leaving it undefined.
It's not a half-definition. It's very clear in that it's not supporting
some architectures (that may not expose shared memory windows then).

All the Best,

More information about the mpiwg-rma mailing list