[Mpi3-rma] Conflicting accesses

[Barrett, Brian W]

On Dec 13, 2010, at 2:54 PM, Torsten Hoefler wrote:

> On Sun, Dec 12, 2010 at 08:14:05PM -0700, Underwood, Keith D wrote:
>> In theory, this example should work in the new proposal, but what does
>> that have to do with your text above the example?  You wrote two
>> paragraphs about lockall/shared and your example is lock(exclusive).
>> If it is not an exclusive lock, then this should work - as long as you
>> could guarantee that there would be no conflicting accesses from other
>> nodes.  I'm not sure how useful this example would be without an
>> exclusive lock...  We shouldn't give this example without an exclusive
>> lock without a LOT of big BOLD warning text ;-)
> Yes, the example was exclusively locked (which is what Jim did in his
> code). However, I would say that it's important to also allow this
> within shared lock epochs. But this would then force us to define
> something like a pairwise consistency, i.e., conflicting accesses are
> only guaranteed to produce useful outcome if they are between the same
> source-destination pair and if they are separated by flush calls. This
> is what is implied right now (if we remove the "for example" sentence).
> 
> However, we have another problem in lockall/shared. I'd say the
> following should be valid too:
> 
> Rank 0:
> MPI_Put(rank=1, addr=0)
> MPI_Flush(rank=1)
> MPI_Barrier()
> 
> Rank 1:
> MPI_Barrier()
> 
> Rank 2:
> MPI_Barrier()
> MPI_Get(rank=1, addr=0)
> 
> 
> 
> I think this is implied with the current semantics too, do we all agree?
> 
> Put and Get are conflicting, however, they are separated by a Flush and
> the according dependencies. We should make this more explicit (could be
> tricky to define).


I believe that the current rules would allow it (at least, I couldn't find anything that would disallow it, since we discuss conflicting accesses in terms of "becoming visible in the public window", which the flush would guarantee occurred.  Is there any chance the non-unified model could have issues with this?

Brian

-- 
  Brian W. Barrett
  Dept. 1423: Scalable System Software
  Sandia National Laboratories