[Mpi3-rma] Conflicting accesses

[Barrett, Brian W]

Like Rajeev, I can't find the "For example" text Torsten's talking about.  But I agree that the text on page 10 does seem to make it sound like the example Torsten gives should be valid.  Further, I would think the following example would also be valid:

lockall(shared)
get(tail)
flush()
do {
  compare_and_swap(new_tail, tail, tmp)
} while (tail != tmp)
unlockall(shared)

So maybe that's good enough...

Brian

On Dec 12, 2010, at 8:14 PM, 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 ;-)
> 
> Keith
> 
>> -----Original Message-----
>> From: mpi3-rma-bounces at lists.mpi-forum.org [mailto:mpi3-rma-
>> bounces at lists.mpi-forum.org] On Behalf Of Torsten Hoefler
>> Sent: Saturday, December 11, 2010 5:51 PM
>> To: mpi3-rma at lists.mpi-forum.org
>> Subject: [Mpi3-rma] Conflicting accesses
>> 
>> Hi all,
>> 
>> We discussed the issue with the lockall/shared mode that the outcome of
>> overlapping puts or put/get will be undefined. Our discussion ended at
>> a
>> point where we believed that such accesses are not valid in
>> lockall/shared because there is only one access/exposure epoch.
>> 
>> The statement (not in MPI-2) at the end of page 42 seems to imply that.
>> However, I don't think that anything on page 10 (the rules for
>> conflicting accesses) mandate this. Jim created this interesting
>> example
>> and both of us think it should be legal to do (without unlocking as was
>> required in MPI-2):
>> 
>> lock(exclusive)
>> get(tail)
>> flush()
>> put(tail)
>> unlock()
>> 
>> It should be true because flush() implies completion at the target
>> which
>> means that the "mini-epoch" is now finished (yes, in MPI-2, we needed
>> to
>> close an epoch to get completion, however, in MPI-3 we don't).
>> 
>> Do we all agree? I'd like to remove the sentence starting with "For
>> example" on page 42.
>> 
>> 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
>> _______________________________________________
>> mpi3-rma mailing list
>> mpi3-rma at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
> 
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
> 

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