[Mpi3-rma] Proposal 1 discussion points for next telecon

Torsten Hoefler htor at illinois.edu
Mon Oct 25 17:15:18 CDT 2010

Hi RMA Working Group,

Bill and I finished the edits on proposal 1 (see wiki). 

We have several points to discuss in the next telecon:

1) We should work on a more generic info mechanism which solves the info
attach, detach and query problems we mentioned (however, it should not
be limited to RMA/windows)

2) We should discuss the register/deregister interface. Right now it
has base and size. This has several issues. One possible solution would
be to return a handle that is needed to free the memory. This has issues
too. We put both choices into the current draft and should discuss.

3) CAS needs a query to determine if a datatype is hardware-optimized.
We think it should use RMA_Query for this and assume that anything that
returns the RMA unified model is hw optimized

4) Discuss difference between lock-free synchronization and lock/unlock.
The semantics of lock-free are different from a lock-all/shared epoch.
The main difference is that holding a "shared" lock means that the user
guarantees that there are no conflicting accesses (if there are, then he
can often "upgrade" to an exclusive lock). So this is consistent with
the literature on concurrent programming. If we now allow conflicting
accesses (remember that MPI-2 defines a "conflicting" access on a
per-window granularity) in lock-shared then this would break this
semantic property. One would also need to allow this for the single-lock
epochs and this could cost us several optimizations.

5) Do we need ordering semantics for any other synchronization mode? I
would like to keep it a bit separate for now (i.e., in the lockfree
synch mode), however, it would not be hard to specify it also for other
modes. Are there use-cases?

6) We added a sentence about the access granularity to 11.5.5 (lockfree
synchronization). This is because we have to allow conflicting accesses
(load/store + put/get etc.) in the same epoch on a window. The
granularity there is aligned with MPI's access granularity (i.e.,
datatype sizes). We avoided to mention anything in bytes or such.

I uploaded the latest working version to the wiki at 

Thanks a lot,
 Torsten & Bill

 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

More information about the mpiwg-rma mailing list