[Mpi3-rma] Conflicting accesses

Torsten Hoefler htor at illinois.edu
Mon Dec 13 15:54:04 CST 2010


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).

All the Best,
  Torsten

-- 
 bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ -----
Torsten Hoefler         | Performance Modeling and Simulation Lead
Blue Waters Directorate | University of Illinois (UIUC)
1205 W Clark Street     | Urbana, IL, 61801
NCSA Building           | +01 (217) 244-7736



More information about the mpiwg-rma mailing list