- Mpi-22 - mailman3.cels.anl.gov

Re: [Mpi-22] Ordering guarantees and multiple threads
by unknown＠example.com 27 Mar '09

27 Mar '09

The standard already says: If a sender sends two messages in succession to the same destination, and both match the same receive, then this operation cannot receive the second message if the first one is still pending. If a receiver posts two receives in succession, and both match the same message, then the second receive operation cannot be satisfied by this message, if the first one is still pending. This requirement facilitates matching of sends to receives. It guarantees that message-passing code is deterministic, I think that already provides the appropriate guarantee. Two concurrent threads making MPI calls do not provide any enforcement of "?succession" and the standard points this out to be helpful. It should not really have been necessary to say this. Explicit temporal ordering of actions on otherwise concurrent threads by an application is common and it is not the job of the MPI standard to say how this is to be done. MPI should probably only say in any situation where "?succession" is ambiguous, MPI makes no guarantee of disambiguation. Where "succession" is clear cut, MPI will reflect the succession order. Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-22-bounces_at_[hidden] wrote on 03/27/2009 01:25:29 PM: > [image removed] > > Re: [Mpi-22] Ordering guarantees and multiple threads > > Greg Bronevetsky > > to: > > MPI 2.2, MPI 2.2 > > 03/27/2009 01:27 PM > > Sent by: > > mpi-22-bounces_at_[hidden] > > Please respond to "MPI 2.2" > > At 09:35 AM 3/27/2009, Darius Buntinas wrote: > > >I've just created a ticket: > > https:// svn.mpi-forum.org/trac/mpi-forum-web/ticket/144 > >to suggest that we strengthen the ordering guarantees between sends (and > >receives) from different threads. > > > >I think that the real question here is whether the potential benefit to > >the user outweighs the potential for optimization in a multithreaded > >implementation. > > > >Please have a look at it and feel free to comment. > > I like the spirit of this proposal but in practice it will be hard to > specify. In particular, consider the sentence "two sends do not > overlap if the first MPI_Send() returns before the second MPI_Send() > is called". The word "before" here is only properly defined on a > sequentially consistent memory. On any other memory model "before" is > only defined by synchronization primitives supplied by the shared > memory system. As such, I don't know how to be precise about > something like "before" without talking about the shared memory > system. This will be hard because we'll need to talk about concepts > that all these systems share but for which they all provide different > primitives and semantics. I don't know how the wider forum will react > to such a specification. However, I agree that something like this is > necessary. > > Greg Bronevetsky > Post-Doctoral Researcher > 1028 Building 451 > Lawrence Livermore National Lab > (925) 424-5756 > bronevetsky1_at_[hidden] > http://greg.bronevetsky.com > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 *

1 0

Re: [Mpi-22] Ordering guarantees and multiple threads
by unknown＠example.com 27 Mar '09

27 Mar '09

At 09:35 AM 3/27/2009, Darius Buntinas wrote: >I've just created a ticket: > https:// svn.mpi-forum.org/trac/mpi-forum-web/ticket/144 >to suggest that we strengthen the ordering guarantees between sends (and >receives) from different threads. > >I think that the real question here is whether the potential benefit to >the user outweighs the potential for optimization in a multithreaded >implementation. > >Please have a look at it and feel free to comment. I like the spirit of this proposal but in practice it will be hard to specify. In particular, consider the sentence "two sends do not overlap if the first MPI_Send() returns before the second MPI_Send() is called". The word "before" here is only properly defined on a sequentially consistent memory. On any other memory model "before" is only defined by synchronization primitives supplied by the shared memory system. As such, I don't know how to be precise about something like "before" without talking about the shared memory system. This will be hard because we'll need to talk about concepts that all these systems share but for which they all provide different primitives and semantics. I don't know how the wider forum will react to such a specification. However, I agree that something like this is necessary. Greg Bronevetsky Post-Doctoral Researcher 1028 Building 451 Lawrence Livermore National Lab (925) 424-5756 bronevetsky1_at_[hidden] http://greg.bronevetsky.com

1 0

Ordering guarantees and multiple threads
by unknown＠example.com 27 Mar '09

27 Mar '09

I've just created a ticket: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/144 to suggest that we strengthen the ordering guarantees between sends (and receives) from different threads. I think that the real question here is whether the potential benefit to the user outweighs the potential for optimization in a multithreaded implementation. Please have a look at it and feel free to comment. Thanks, -d

1 0

Re: [Mpi-22] Ticket #71: Add routine for registering callback when finalize occurs
by unknown＠example.com 26 Mar '09

26 Mar '09

Why would this be specific to MPI_COMM_SELF? If this is the right thing to do, shouldn't it apply to attribute delete functions on all disposed objects? Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-22-bounces_at_[hidden] wrote on 03/26/2009 12:50:40 PM: > [image removed] > > [Mpi-22] Ticket #71: Add routine for registering callback when finalize occurs > > Quincey Koziol > > to: > > mpi-22 > > 03/26/2009 12:54 PM: > > Sent by: > > mpi-22-bounces_at_[hidden] > > Please respond to "MPI 2.2" > > Hi all, > Could another two people review this ticket for specifying the order > that attribute delete callbacks should be made: > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/71 > > Thanks, > Quincey > > [attachment "smime.p7s" deleted by Richard Treumann/Poughkeepsie/ > IBM] _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 *

1 0

Ticket #71: Add routine for registering callback when finalize occurs
by unknown＠example.com 26 Mar '09

26 Mar '09

Hi all, Could another two people review this ticket for specifying the order that attribute delete callbacks should be made: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/71 Thanks, Quincey *

1 0

please review ticket #143: MPI_Request_free bad advice to users
by unknown＠example.com 25 Mar '09

25 Mar '09

Please review ticket #143: MPI_Request_free bad advice to users<https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/143> for MPI 2.2. I moved the original proposal (ticket #47<https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/47>) to deprecate MPI_Request_free for active requests to MPI 3.0. Thanks, .Erez *

1 0

Ticket #33: Fix Scalability Issues in Graph Topology Interface
by unknown＠example.com 25 Mar '09

25 Mar '09

We need more people reviewing this ticket to see if this is the right way to fix the scalability problem with graph topologies. Among the new features proposed in 2.2, it is a significant one and is not trivial to understand and vote on unless you have studied it beforehand. Rajeev Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/33

1 0

Re: [Mpi-22] [MPI Forum] #102: MPI_TYPE_GET_EXTENT is defined via deprecated features
by unknown＠example.com 24 Mar '09

24 Mar '09

Since "upper bound" and "lower bound" still exist and therefore the concept of MPI_LB and MPI_UB still exist, it seems like we should do one of two things: 1) Retract this proposal and leave it the way it is. 2) Go through the whole chapter and carefully separate out the concept of the upper/lower bounds from the MPI_UB/MPI_LB markers. We would need to present the concept using general terms which could be then referenced in the definition of MPI_TYPE_GET_EXTENT. The presentation and references to MPI_UB/MPI_LB would need to be confined to a limited area and clearly designated at depreciated. I doubt that #2 is worth the effort or will not introduce more new errors than what it is attempting to fix. As it stands now, I still think it is a little awkward to read the chapter because MPI_LB and MPI_UB were central to the original presentation and now we have deprecated them. Still, I do not see a fix simple enough to be worthy of such a minor nit. Dave -----Original Message----- From: MPI Forum [mailto:mpi-22_at_[hidden]] Sent: Tuesday, March 24, 2009 12:02 PM Subject: Re: [MPI Forum] #102: MPI_TYPE_GET_EXTENT is defined via deprecated features #102: MPI_TYPE_GET_EXTENT is defined via deprecated features --------------------------------+--------------------------------------- --------------------------------+---- Reporter: RolfRabenseifner | Owner: dgsolt Type: Text (only) changes | Status: new Priority: Waiting for reviews | Milestone: 2009/04/06 Chicago Version: MPI 2.2 | Resolution: Keywords: | Implementation: Unnecessary --------------------------------+--------------------------------------- --------------------------------+---- Changes (by RolfRabenseifner): * implementation: => Unnecessary Comment: The current proposal does not solve any problem, because on p78 Formula (4.1), an epsilon is used, which is defined in the next three lines, which end with a pointer to page 96. The new concept has still a lb&ub-concept that seems to be identical to the previous, i.e., the formulas on page 78 do not help (they are without lb und ub). The formulas on page 96 are the only valid formulas that explain the lb in the new routines MPI_Type_get_extent and MPI_Type_create_resized. p98.3-4 clearly tell about new pait of lower bound and upper bound markers. Proposal: remove MPI_LB and MPI_UB and substitute nearly each location by "lower bound (lb) marker" and "upper bound (ub) marker". -- Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/102#comment:7> MPI Forum <https://svn.mpi-forum.org/> MPI Forum

1 0

Re: [Mpi-22] MPI_Aint/MPI_ADDRESS_KIND equivalence and ticket #18
by unknown＠example.com 23 Mar '09

23 Mar '09

On Mar 9, 2009, at 2:17 PM, Jeff Squyres wrote: > On Mar 9, 2009, at 2:34 PM, Rajeev Thakur wrote: > >> Address-sized variables in MPI can be passed from C to Fortran or >> vice >> versa, and I know of no c2f or f2c conversion functions for them. >> So I think >> MPI_Aint and integer (kind=MPI_ADDRESS_KIND) are assumed to be of >> the same >> size at least implicitly. >> > > I agree. Should we state this explicitly somewhere (if we didn't > already)? FYI, I've created ticket #141 to clarify the text in this regard: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/141 -Dave

1 0

Please review ticket #140: Add const Keyword to the C bindings
by unknown＠example.com 23 Mar '09

23 Mar '09

I opened a new ticket #140<https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/140> for the "Add const Keyword to the C bindings" proposal instead of existing tickets #46<https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/46>, #129<https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/129> & #130<https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/130>. Ticket #140 differs from ticket #46 only by the applied amendments in tickets #129 and #130. Chapter authors please review this ticket before the next forum meeting. Thanks, .Erez *

1 0