I must admit I have not been able to properly follow all the discussions going on, but as a casual observer and one-time implementer I have concerns. I don't see the problems that I had trying to optimize MPI RMA implementations being addressed. It seems to me that having a robust API that can't be implemented efficiently is as bad as having an insufficient API. The problems I had with MPI2 RMA seem to be centered on the fact that all synchronization methods could be used on the same window indiscriminately throughout the program. This makes it very difficult to optimize an implementation because of all the corner-cases and state information that must be dealt with. With new interfaces being heaped on top of old ones, I see the problem only getting worse. It really seems to me that the MPI2 RMA should be thrown out and redesigned. I know that's not possible, especially at this late time, and I hope I have not insulted anyone by saying this. There's no need to respond to that statement (unless people actually think that's a reasonable track). But, what about having some restrictions on what synchronization that a window will use. I would envision either different window types altogether (e.g. MPI_Win_create_lock, MPI_Win_create_pscw, ...) or at least some sort of assert parameter (which must be specified) to establish at cerate time how a window will be synchronized. At the very least then, internally I could add a function table to the window object that selected optimized routines based on the window usage. And, without eliminating (deprecating, etc) the existing API I don't see how optimizations can be realized. Hope I haven't kicked the proverbial hornets nest. _______________________________________________ Douglas Miller BlueGene Messaging Development IBM Corp., Rochester, MN USA Bldg 030-2 A410 [email protected] Douglas Miller/Rochester/IBM