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

Ewww... yeah, I think that should work. Would this also work? It might be cheaper and easier to program than the barrier... Rank 0: (addr 42 starts as 0) MPI_Put(rank=1, addr=0, size=1912) MPI_Flush(rank=1) MPI_Accumulate(rank=1, addr=42, MPI_REPLACE, 1) MPI_Flush(rank=1) Rank 1: while (temp == 0) {MPI_GetAccumulate(rank=1, addr=42, &temp); MPI_Flush(rank=1);} MPI_Get(rank=1, addr=12)