Hello all, I apologize for the cross-post but this is of interest to two groups. I have an alternative proposal for the shared memory support. I believe that it would naturally integrate into the One Sided chapter as a special type of window. This would save some additional function calls and seems to make semantical definitions tighter and the whole standard more orthogonal. Thanks to Brian, Bill, Marc, and Ron for preliminary discussions of the idea. Here is the proposed new call: MPI_Win_allocate_shared(size, info, comm, *baseptr, *win); This would create a special window in the "unified" model which is referencing the same physical memory on all processes in a shared memory domain. The group of processes that share memory can be queried with MPI_Win_get_group() and a new MPI_WIN_FLAVOR_SHARED would be added as window type. The whole concept is even mightier because one could now support NCC shared memory (I remember than Hubert mentioned that in one of the discussions) if we would allow the "separate" window type for it. However, this seems to introduce all kinds of complex interactions (e.g., does everybody logically have it's own public copy of the *same* memory). I'm not proposing this at this point but it might be worth a discussion! This would make the new proposed calls "MPI_COMM_SHM_FREE(shm)" and "MPI_SHM_FENCE" superfluous and would enable all synchronizations and portable (!!) atomic operations that we defined in the RMA chapter immediately. This would also remove the need to have a special MPI_COMM_SHM as required in the hybrid proposal. Any comments are welcome. I can talk about this at the next meeting (most likely in the RMA group on Tuesday). 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