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

[Rajeev Thakur]

Thanks. Some comments:

* The change from win_allmem to dynamic is a good one.

* pg 23, ln 36: Instead of "Passive target communication" I think you mean "Lock-free passive target synchronization"

* pg 35, ln 22-23: Move "locally at the origin" to earlier in the sentence: "Completes locally at the origin all outstanding..."

* pg 35, ln 45: Some more clarification is needed about what happens in a Win_membar. For example, if the user calls it somewhere in the midst of a fence epoch, what can he expect?

* pg 36: Does Win_lockfree also need a Win_unlockfree? Is this mode useful only in the unified model? Or in other words, how would one use it in the separate model? It is also worth mentioning in the description how a put or get can be completed in this model, i.e. with a flush or test/wait.

* pg 38, ln16-17: Could be rephrased as "only operations that have the unified memory model will be performed on this window" since the user doesn't set the memory model of the operation but uses operations that already have an implementation-specified memory model.

* pg 45: In Example 11.12, is the Win_membar needed in the unified model where public and private copies are already the same? Similarly in Example 11.14 on pg 46.

Rajeev

On Oct 25, 2010, at 5:15 PM, Torsten Hoefler wrote:

> 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 
> https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/mpi3-rma-proposal1/one-side-2.pdf
> 
> 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
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma