alt. proposal

Raja Daoud (raja@tbag.rsn.hp.com)
Wed, 10 Jul 1996 12:13:37 CDT

Thanks for re-clarifying the alt. proposal Marc. In addition to
simplifying the interface, I like that it is explicit about the two
programming styles: barriers, and the shared memory approach using
locks. For portable systems that do not want to slow down MPI by using
agents and/or signals, it's nice to know they will be able to fully
support the barrier style of programming (I think it's also the most
prevalent style among the small subset of codes that require 1-sided).

As Marc suggested on lines 4-5, I propose that we get rid of the RMW
operations as a further simplification (so now it's officially proposed).

I also propose adding a predefined attribute key to the window's
communicator (I'm not attached to this particular name):

MPI_WINDOW_RELAXED_MODEL Boolean variable that indicates whether
the "relaxed-model" is followed.

If the value is set to 1, the 1-sided usage is restricted to the
relaxed-model on that window (i.e. the window owner must participate by
calling MPI for lock/unlock operations to complete). If the key is not
defined, or the value is set to 0, the strict shared memory model can be
assumed by the user.

High quality implementations are expected to follow the strict shared
memory model. Note: this is consistent with the more inclusive handler
approach of allowing non-threaded libraries to only progress the handler
when MPI is called (instead of tying them to threaded libraries).

This gives us a balance between some user demands (but not all 1-sided
users users require it, some are happy with barrier) and mandates on
implementation complexity. It's the "big tent" inclusive view, with
different qualities of implementation.

--Raja

-=-
Raja Daoud Hewlett-Packard Co.
raja@rsn.hp.com Convex Division