1) It requires "special" communicators in order to perform RWM.
2) Behavior when copying communicators becomes confusing.
3) It only allows one type of operation per communicator.
4) It provides no locality hints to MPI.
5) It provides no obvious way to perform non-destructive reads.
6) It forces users to call a RMW_INIT function.
Some of these needs are addressed by Marc's alternative model, but that's
probably a seperate issue. So, within the context of the current chapter I
would like to propose a different API which addresses all of the above
limitations:
MPI_RMW(invar, outvar, op, rank, comm)
The big difference here is that there is no single "value" that is associated
with an entire communicator. Rather, each member of the communicator has its
own *local* value that is completely independent of the others. The rank
argument therefore determines which process in the communicator will have its
value modified. The other arguments have the same meaning as in the current
text.
Advantages:
1) Does not require special/new communicators.
2) Creating new communicators is now straightforward.
3) Supports different kinds of operations on the same value.
4) Applications can now tune for locality.
5) By adding a new MPI_READ op, non-destructive reads can easily be supported.
6) Does not require RMW_INIT.
Disadvantages:
1) Each communicator must now carry an additional 32 bits of state to hold the
local RMW var. Not a Big Deal.
2) The text mentions that moving the op argument into the RMW call will prevent
optimizations on machines with special hardware. I do not understand why
this is so, could someone please elaborate on this?
Comments?
-- Eric Salo Silicon Graphics Inc. "Do you know what the (415)933-2998 2011 N. Shoreline Blvd, 8U-808 last Xon said, just salo@sgi.com Mountain View, CA 94043-1389 before he died?"