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