- Mpi-21 - mailman3.cels.anl.gov

Re: [mpi-21] Ballot 4 - Re: Request for interpretation
by unknown＠example.com 31 Jan '08

31 Jan '08

As you are saying, there are two different classes of errors here. 1) Keys which are not understood and need to be ignored by functions which don't grok them ("JIMS_SECRET_TAG","99") 2) Keys which are understood by a function, but with a value which is not ("buffer_size", "Hello") I think allowing the second type to have undefined behavior is the right thing to do, since it's the most general. If your implementation wants to define the behavior of some out-of-range values, that's fine and doesn't make you non-conforming, it just means you defined the previously undefined behavior for some set of values. Having that undefined-ness explicit here (in one central place) seems to make sense (if only because it may be omitted in one of the other places where it should appear). My addition does not alter the existing change which guarantees case 1, it's only concerned with case 2. -- Jim James Cownie <james.h.cownie_at_[hidden]> SSG/DPD/PAT Tel: +44 117 9071438 ________________________________ From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] On Behalf Of Richard Treumann Sent: 31 January 2008 14:20 To: Mailing list for discussion of MPI 2.1 Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation Jim - I was taking the view that the description of what to do for a recognized key but dubious value belongs to the function that recognizes the specific key. For example if MPI_File_open accepts a "buffer_size" hint with range "32K" to "16M" we may want to define the behavior of hints that are out of range. Once we say an info can have arbitrary keys we need to state that every info consumer must be prepared to ignore keys it does not recognize because we have made unrecognizable keys legitimate. Dick Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-21-bounces_at_[hidden] wrote on 01/31/2008 08:43:04 AM: > However, you have apparently lost the liberty to have undefined > behavior which was there in the previous version. > > Maybe you should keep that, something like > An implementation must support info objects as caches for arbitrary > (key, value) pairs, regardless of whether it recognizes the keys. > Each MPI function which takes hints in the form of an MPI_Info must > be prepared to ignore any key it does not recognize. However if a > function recognizes a key but not the associated value, then the > behavior is undefined. > (Modifications in italics) > -- Jim > > James Cownie <james.h.cownie_at_[hidden]> > SSG/DPD/PAT > Tel: +44 117 9071438 > > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] > On Behalf Of Richard Treumann > Sent: 31 January 2008 13:29 > To: Mailing list for discussion of MPI 2.1 > Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation > > Your wording works for me Rolf. -- Thanks > > > Dick Treumann - MPI Team/TCEM > IBM Systems & Technology Group > Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > > > mpi-21-bounces_at_[hidden] wrote on 01/31/2008 05:25:46 AM: > > > I try to summarize all 3 replies in one proposal: > > > > ___________________________________ > > > > Proposal: > > MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38-40 read: > > If a function does not recognize a key, > > it will ignore it, unless otherwise specified. > > If an implementation recognizes a key but does not recognize > > the format of the corresponding value, the result is undefined. > > but should read: > > An implementation must support info objects as caches for arbitrary > > (key, value) pairs, regardless of whether it recognizes the pairs. > > Each MPI function which takes hints in the form of an MPI_Info must > > be prepared to ignore any key it does not recognize. > > > > Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new > > paragraph: > > Advice to implementors. > > Although in MPI functions that take hints in form of an MPI_Info > > (e.g., in process creation and management, one-sided communication, > > or parallel file I/O), an implementation must be prepared to ignore > > keys that it does not recognize, for the purpose of MPI_INFO_GET_NKEYS, > > MPI_INFO_GET_NTHKEY, MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the > > implementation must retain all (key,value) pairs so that layered > > functionality can also use the Info object. > > (End of advice to implementors.) > > _____________________________ > > Rationale for this clarification: > > > > The MPI-2.0 text allowed that also MPI_INFO_DELETE, MPI_INFO_SET, > > MPI_INFO_GET, and MPI_INFO_DUP could ignore (key,value) pairs > > that are not recognized in routines in other chapters that > > take hints with info arguments. > > The proposed clarification is necessary when we assume, that > > layered implementation of parts of the MPI-2 standard should > > be possible and may use the MPI_Info objects for their needs. > > This was a goal of the MPI-2 Forum and the MPI-2.0 specification. > > ___________________________________ > > > > Bronis, for me, your wording "an MPI implementation may restrict" was > > in conflict with the rest of the advice. I hope the formulation above > > is also okay. It is based on the new wording from you and Dick in first > > part of the proposal. > > > > Best regards > > Rolf > > > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > > _______________________________________________ > > mpi-21 mailing list > > mpi-21_at_[hidden] > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > --------------------------------------------------------------------- > Intel Corporation (UK) Limited > Registered No. 1134945 (England) > Registered Office: Pipers Way, Swindon SN3 1RJ > VAT No: 860 2173 47 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. *

1 0

Ballot 4 - MPI_THREAD_FUNNELED - was Re: Attending, topics, etc
by unknown＠example.com 31 Jan '08

31 Jan '08

This is a proposal for MPI 2.1, Ballot 4. I'm asking especially Greg Lindahl, the participants of the email-discussion in 2007, to review this proposal. This is a follow up to: Which thread is the funneled thread? in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… with mail discussion in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… ___________________________________ Proposal: MPI-2.0 Sect. 8.7.3, MPI_Init_thread, page 196, lines 25-26 read: MPI_THREAD_FUNNELED The process may be multi-threaded, but only the main thread will make MPI calls (all MPI calls are "funneled" to the main thread). but should read: MPI_THREAD_FUNNELED The process may be multi-threaded, but only the main thread will make MPI calls (all MPI calls are "funneled" to the main thread, e.g., by using the OpenMP directive "master" in the application program). ___________________________________ Rationale for this clarification from the email from Greg Lindahl: The existing document doesn't make it clear that the MPI user has to funnel the calls to the main thread; it's not the job of the MPI library. I have seen multiple MPI users confused by this issue, and when I first read this section, I was confused by it, too. ___________________________________ Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [mpi-21] Ballot 4 - MPI_File_get_info
by unknown＠example.com 31 Jan '08

31 Jan '08

I think this proposal is moot unless it is intended as a loophole to allow an implementation to provide a zero-functionality version of the INFO bindings. The "filename" hint is always present on an MPI_File so there should never be a empty MPI_FILE_GET_INFO return. Dick hh Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-21-bounces_at_[hidden] wrote on 01/31/2008 08:01:20 AM: > This is a proposal for MPI 2.1, Ballot 4. > > I'm asking especially the implementors to check, whether > this interpretation is implemented in their MPI implementations, > or does not contradict to the existing implementation. > > This is a follow up to: > MPI_File_get_info > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/index.html > with mail discussion not yet existing > ___________________________________ > > Proposal: > MPI-2.0 Sect. 9.2.8, File Info, page 219, lines 11-13 read: > > MPI_FILE_GET_INFO returns a new info object containing the hints > of the file associated with fh. The current setting of all hints > actually used by the system related to this open file is returned > in info_used. > The user is responsible for freeing info_used via MPI_INFO_FREE. > > but should read (" or an abort(errorcode)" removed): > > MPI_FILE_GET_INFO returns a new info object containing the hints > of the file associated with fh. The current setting of all hints > actually used by the system related to this open file is returned > in info_used. > If there does not exist such a hint, MPI_INFO_NULL is returned. > The user is responsible for freeing info_used via MPI_INFO_FREE > if info_used is not MPI_INFO_NULL. > ___________________________________ > Rationale for this clarification: > This text was missing. It was not clear, whether a MPI_Info handle > would be returned that would return nkeys=0 from MPI_INFO_GET_NKEYS. > From user's point of view, this behavior might have been expected > without this clarification. > ___________________________________ > > As far as I understand, ROMIO is using for all filesystems some default > hints and therefore "no-hints" is never returned. > MPI_File_set_view and MPI_File_set_info are only modifying values > but do not remove keys. > Therefore, the info handle cannot become empty. > > Best regards > Rolf > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 *

1 0

Re: [mpi-21] Ballot 4 - Re: Request for interpretation
by unknown＠example.com 31 Jan '08

31 Jan '08

Sorry, that was my fault. Here again the full proposal including your sentence (and nothing else changed): ___________________________________ Proposal: MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38-40 read: If a function does not recognize a key, it will ignore it, unless otherwise specified. If an implementation recognizes a key but does not recognize the format of the corresponding value, the result is undefined. but should read: An implementation must support info objects as caches for arbitrary (key, value) pairs, regardless of whether it recognizes the pairs. Each MPI function which takes hints in the form of an MPI_Info must be prepared to ignore any key it does not recognize. However if a function recognizes a key but not the associated value, then the behavior is undefined. Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new paragraph: Advice to implementors. Although in MPI functions that take hints in form of an MPI_Info (e.g., in process creation and management, one-sided communication, or parallel file I/O), an implementation must be prepared to ignore keys that it does not recognize, for the purpose of MPI_INFO_GET_NKEYS, MPI_INFO_GET_NTHKEY, MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the implementation must retain all (key,value) pairs so that layered functionality can also use the Info object. (End of advice to implementors.) _____________________________ Rationale for this clarification: The MPI-2.0 text allowed that also MPI_INFO_DELETE, MPI_INFO_SET, MPI_INFO_GET, and MPI_INFO_DUP could ignore (key,value) pairs that are not recognized in routines in other chapters that take hints with info arguments. The proposed clarification is necessary when we assume, that layered implementation of parts of the MPI-2 standard should be possible and may use the MPI_Info objects for their needs. This was a goal of the MPI-2 Forum and the MPI-2.0 specification. ___________________________________ Best regards Rolf On Thu, 31 Jan 2008 13:43:04 -0000 "Cownie, James H" <james.h.cownie_at_[hidden]> wrote: >However, you have apparently lost the liberty to have undefined behavior >which was there in the previous version. > > > >Maybe you should keep that, something like > >An implementation must support info objects as caches for arbitrary >(key, value) pairs, regardless of whether it recognizes the keys. Each >MPI function which takes hints in the form of an MPI_Info must >be prepared to ignore any key it does not recognize. However if a >function recognizes a key but not the associated value, then the >behavior is undefined. > >(Modifications in italics) > >-- Jim > >James Cownie <james.h.cownie_at_[hidden]> >SSG/DPD/PAT >Tel: +44 117 9071438 > >________________________________ > >From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] On >Behalf Of Richard Treumann >Sent: 31 January 2008 13:29 >To: Mailing list for discussion of MPI 2.1 >Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation > > > >Your wording works for me Rolf. -- Thanks > > >Dick Treumann - MPI Team/TCEM >IBM Systems & Technology Group >Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 >Tele (845) 433-7846 Fax (845) 433-8363 > > >mpi-21-bounces_at_[hidden] wrote on 01/31/2008 05:25:46 AM: > >> I try to summarize all 3 replies in one proposal: >> >> ___________________________________ >> >> Proposal: >> MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38-40 read: >> If a function does not recognize a key, >> it will ignore it, unless otherwise specified. >> If an implementation recognizes a key but does not recognize >> the format of the corresponding value, the result is undefined. >> but should read: >> An implementation must support info objects as caches for arbitrary >> (key, value) pairs, regardless of whether it recognizes the pairs. >> Each MPI function which takes hints in the form of an MPI_Info must >> be prepared to ignore any key it does not recognize. >> >> Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new >> paragraph: >> Advice to implementors. >> Although in MPI functions that take hints in form of an MPI_Info >> (e.g., in process creation and management, one-sided communication, > >> or parallel file I/O), an implementation must be prepared to ignore > >> keys that it does not recognize, for the purpose of >MPI_INFO_GET_NKEYS, >> MPI_INFO_GET_NTHKEY, MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the >> implementation must retain all (key,value) pairs so that layered >> functionality can also use the Info object. >> (End of advice to implementors.) >> _____________________________ >> Rationale for this clarification: >> >> The MPI-2.0 text allowed that also MPI_INFO_DELETE, MPI_INFO_SET, >> MPI_INFO_GET, and MPI_INFO_DUP could ignore (key,value) pairs >> that are not recognized in routines in other chapters that >> take hints with info arguments. >> The proposed clarification is necessary when we assume, that >> layered implementation of parts of the MPI-2 standard should >> be possible and may use the MPI_Info objects for their needs. >> This was a goal of the MPI-2 Forum and the MPI-2.0 specification. >> ___________________________________ >> >> Bronis, for me, your wording "an MPI implementation may restrict" was >> in conflict with the rest of the advice. I hope the formulation above >> is also okay. It is based on the new wording from you and Dick in >first >> part of the proposal. >> >> Best regards >> Rolf >> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > >--------------------------------------------------------------------- >Intel Corporation (UK) Limited >Registered No. 1134945 (England) >Registered Office: Pipers Way, Swindon SN3 1RJ >VAT No: 860 2173 47 > >This e-mail and any attachments may contain confidential material for >the sole use of the intended recipient(s). Any review or distribution >by others is strictly prohibited. If you are not the intended >recipient, please contact the sender and delete all copies. Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [mpi-21] Ballot 4 - Re: Request for interpretation
by unknown＠example.com 31 Jan '08

31 Jan '08

Jim - I was taking the view that the description of what to do for a recognized key but dubious value belongs to the function that recognizes the specific key. For example if MPI_File_open accepts a "buffer_size" hint with range "32K" to "16M" we may want to define the behavior of hints that are out of range. Once we say an info can have arbitrary keys we need to state that every info consumer must be prepared to ignore keys it does not recognize because we have made unrecognizable keys legitimate. Dick Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-21-bounces_at_[hidden] wrote on 01/31/2008 08:43:04 AM: > However, you have apparently lost the liberty to have undefined > behavior which was there in the previous version. > > Maybe you should keep that, something like > An implementation must support info objects as caches for arbitrary > (key, value) pairs, regardless of whether it recognizes the keys. > Each MPI function which takes hints in the form of an MPI_Info must > be prepared to ignore any key it does not recognize. However if a > function recognizes a key but not the associated value, then the > behavior is undefined. > (Modifications in italics) > -- Jim > > James Cownie <james.h.cownie_at_[hidden]> > SSG/DPD/PAT > Tel: +44 117 9071438 > > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] > On Behalf Of Richard Treumann > Sent: 31 January 2008 13:29 > To: Mailing list for discussion of MPI 2.1 > Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation > > Your wording works for me Rolf. -- Thanks > > > Dick Treumann - MPI Team/TCEM > IBM Systems & Technology Group > Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > > > mpi-21-bounces_at_[hidden] wrote on 01/31/2008 05:25:46 AM: > > > I try to summarize all 3 replies in one proposal: > > > > ___________________________________ > > > > Proposal: > > MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38-40 read: > > If a function does not recognize a key, > > it will ignore it, unless otherwise specified. > > If an implementation recognizes a key but does not recognize > > the format of the corresponding value, the result is undefined. > > but should read: > > An implementation must support info objects as caches for arbitrary > > (key, value) pairs, regardless of whether it recognizes the pairs. > > Each MPI function which takes hints in the form of an MPI_Info must > > be prepared to ignore any key it does not recognize. > > > > Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new > > paragraph: > > Advice to implementors. > > Although in MPI functions that take hints in form of an MPI_Info > > (e.g., in process creation and management, one-sided communication, > > or parallel file I/O), an implementation must be prepared to ignore > > keys that it does not recognize, for the purpose of MPI_INFO_GET_NKEYS, > > MPI_INFO_GET_NTHKEY, MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the > > implementation must retain all (key,value) pairs so that layered > > functionality can also use the Info object. > > (End of advice to implementors.) > > _____________________________ > > Rationale for this clarification: > > > > The MPI-2.0 text allowed that also MPI_INFO_DELETE, MPI_INFO_SET, > > MPI_INFO_GET, and MPI_INFO_DUP could ignore (key,value) pairs > > that are not recognized in routines in other chapters that > > take hints with info arguments. > > The proposed clarification is necessary when we assume, that > > layered implementation of parts of the MPI-2 standard should > > be possible and may use the MPI_Info objects for their needs. > > This was a goal of the MPI-2 Forum and the MPI-2.0 specification. > > ___________________________________ > > > > Bronis, for me, your wording "an MPI implementation may restrict" was > > in conflict with the rest of the advice. I hope the formulation above > > is also okay. It is based on the new wording from you and Dick in first > > part of the proposal. > > > > Best regards > > Rolf > > > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > > _______________________________________________ > > mpi-21 mailing list > > mpi-21_at_[hidden] > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > --------------------------------------------------------------------- > Intel Corporation (UK) Limited > Registered No. 1134945 (England) > Registered Office: Pipers Way, Swindon SN3 1RJ > VAT No: 860 2173 47 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 *

1 0

Re: [mpi-21] Ballot 4 proposal: INOUT arguments
by unknown＠example.com 31 Jan '08

31 Jan '08

On Wed, 30 Jan 2008 21:34:31 -0500 Jeff Squyres <jsquyres_at_[hidden]> wrote: >1. Why do we need to indicate the INOUT status of the back-end MPI >object in the language neutral bindings? All the bindings -- >regardless of language -- only deal with the MPI handles, not the back- >end MPI objects. > >2. Adding qualifiers on what is supposed to happen to the back-end MPI >object would seem to require additional semantics on the back-end MPI >object. Should we really be specifying what the implementation must/ >must not do with the back-end MPI object? Who benefits from that? After all the MPI_BOTTOM discussion and not knowing what future languages will bring, I didn't want to remove existing information from the standard. An opaque object in MPI consists always of two things: the handle and the object itself. The language independent interface should reflect this. I thought that especially for the const discussion it would be good to see the IN for the handle. For future HPCS languages, it may be also necessary see the INOUT for the object itself. Best regards Rolf > > >On Jan 29, 2008, at 12:07 PM, Rolf Rabenseifner wrote: > >> Proposal: >> The current text in MPI 2.0 Sect. 2.3 Procedure Specification, >> page 6 lines 30-34 read: >> >> There is one special case  if an argument is a handle to an >> opaque object (these terms are defined in Section 2.5.1), and >> the object is updated by the procedure call, then the argument >> is marked OUT. It is marked this way even though the handle >> itself is not modified  we use the OUT attribute to denote >> that what the handle references is updated. Thus, in C++, >> IN arguments are either references or pointers to const objects. >> >> but should read: >> >> There is one special case  if an argument is a handle to an >> opaque object (these terms are defined in Section 2.5.1), and >> the object is updated by the procedure call >> but the handle itself is not modified , then the argument >> is marked IN/INOUT. >> We use the first part (IN) to specify the use of the handle >> and the second part (INOUT) to specify the use of the opaque >> object. >> Thus, in C++, >> IN arguments are either references or pointers to const objects, >> IN/INOUT arguments are references to const handles to non-const >> objects. >> >> In all reoutines mentioned in the clarification below, >> the INOUT handle declaration (in MPI-2.0) and the IN handle >> declaration >> (in MPI-1.1) ist modified into a IN/INOUT handle declaaration. >> ____________________________ >> >> Rationale for this proposal: >> >> I have checked the total MPI 1.1 and 2.0 standard to find >> all routines with an argument specification according to >> the following declaration pattern: >> >> Language independent interface: >> INOUT handle >> C interface >> MPI_handletype handle >> >> We can find this pattern only in MPI-2.0 at following >> routines: >> >> MPI_INFO_SET / _DELETE >> MPI_xxxx_SET_ERRHANDLER with xxxx=COMM / TYPE / WIN >> MPI_GREQUEST_COMPLETE >> MPI_xxxx_SET_NAME with xxxx=COMM / TYPE / WIN >> MPI_xxxx_SET_ATTR with xxxx=COMM / TYPE / WIN >> MPI_xxxx_DELETE_ATTR with xxxx=COMM / TYPE / WIN >> MPI_FILE_SET_SIZE / _PREALLOCATE / _SET_INFO / _SET_VIEW >> MPI_FILE_WRITE_AT / _WRITE_AT_ALL / _IWRITE_AT >> MPI_FILE_READ / _READ_ALL / _WRITE / _WRITE_ALL >> MPI_FILE_IREAD / _IWRITE >> MPI_FILE_SEEK >> MPI_FILE_READ_SHARED / _WRITE_SHARED >> MPI_FILE_IREAD_SHARED / _IWRITE_SHARED >> MPI_FILE_READ_ORDERED / _WRITE_ORDERED >> MPI_FILE_SEEK_SHARED >> MPI_FILE_WRITE_AT_ALL_BEGIN / MPI_FILE_WRITE_AT_ALL_END >> MPI_FILE_READ_ALL_BEGIN / MPI_FILE_READ_ALL_END >> MPI_FILE_WRITE_ALL_BEGIN / MPI_FILE_WRITE_ALL_END >> MPI_FILE_READ_ORDERED_BEGIN / MPI_FILE_READ_ORDERED_END >> MPI_FILE_WRITE_ORDERED_BEGIN / MPI_FILE_WRITE_ORDERED_END >> MPI_FILE_SET_ATOMICITY / _SYNC >> >> All these routines keep the handle itself unchanged, but the >> opaque object is modified in a way, that with oother MPI routines >> this change can be detected. >> For example, an attribute is cached or changed, a file pointer >> is moved, the content of a file was modified. >> >> The current text in MPI 2.0 Sect. 2.3 Procedure Specification, >> page 6 lines 30-34 read: >> >> There is one special case  if an argument is a handle to an >> opaque object (these terms are defined in Section 2.5.1), and >> the object is updated by the procedure call, then the argument >> is marked OUT. It is marked this way even though the handle >> itself is not modified  we use the OUT attribute to denote >> that what the handle references is updated. Thus, in C++, >> IN arguments are either references or pointers to const objects. >> >> With this definition (that I want to change later on) the use >> of INOUT is correct. >> >> In MPI-1.1 we have several of such routines, but in all cases, >> the handle is declared only as IN. >> >> I hope, I could find all of them: >> >> MPI_ATTR_PUT / _ DELETE >> MPI_ERRHANDLER_SET >> (these routines are now deprecated, but compare with use of >> INOUT in MPI_COMM_SET_ATTR and MPI_COMM_DELETE_ATTR in MPI-2.0) >> >> The following proposal should remove this inconsistency and >> should be a basis for correct definition of const. >> ____________________________ >> >> I hope, with this proposal, the INOUT handle problem can be really >> solved. >> >> Best regards >> Rolf >> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > >-- >Jeff Squyres >Cisco Systems > > >_______________________________________________ >mpi-21 mailing list >mpi-21_at_[hidden] >http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [mpi-21] Ballot 4 - Re: Request for interpretation
by unknown＠example.com 31 Jan '08

31 Jan '08

However, you have apparently lost the liberty to have undefined behavior which was there in the previous version. Maybe you should keep that, something like An implementation must support info objects as caches for arbitrary (key, value) pairs, regardless of whether it recognizes the keys. Each MPI function which takes hints in the form of an MPI_Info must be prepared to ignore any key it does not recognize. However if a function recognizes a key but not the associated value, then the behavior is undefined. (Modifications in italics) -- Jim James Cownie <james.h.cownie_at_[hidden]> SSG/DPD/PAT Tel: +44 117 9071438 ________________________________ From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] On Behalf Of Richard Treumann Sent: 31 January 2008 13:29 To: Mailing list for discussion of MPI 2.1 Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation Your wording works for me Rolf. -- Thanks Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-21-bounces_at_[hidden] wrote on 01/31/2008 05:25:46 AM: > I try to summarize all 3 replies in one proposal: > > ___________________________________ > > Proposal: > MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38-40 read: > If a function does not recognize a key, > it will ignore it, unless otherwise specified. > If an implementation recognizes a key but does not recognize > the format of the corresponding value, the result is undefined. > but should read: > An implementation must support info objects as caches for arbitrary > (key, value) pairs, regardless of whether it recognizes the pairs. > Each MPI function which takes hints in the form of an MPI_Info must > be prepared to ignore any key it does not recognize. > > Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new > paragraph: > Advice to implementors. > Although in MPI functions that take hints in form of an MPI_Info > (e.g., in process creation and management, one-sided communication, > or parallel file I/O), an implementation must be prepared to ignore > keys that it does not recognize, for the purpose of MPI_INFO_GET_NKEYS, > MPI_INFO_GET_NTHKEY, MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the > implementation must retain all (key,value) pairs so that layered > functionality can also use the Info object. > (End of advice to implementors.) > _____________________________ > Rationale for this clarification: > > The MPI-2.0 text allowed that also MPI_INFO_DELETE, MPI_INFO_SET, > MPI_INFO_GET, and MPI_INFO_DUP could ignore (key,value) pairs > that are not recognized in routines in other chapters that > take hints with info arguments. > The proposed clarification is necessary when we assume, that > layered implementation of parts of the MPI-2 standard should > be possible and may use the MPI_Info objects for their needs. > This was a goal of the MPI-2 Forum and the MPI-2.0 specification. > ___________________________________ > > Bronis, for me, your wording "an MPI implementation may restrict" was > in conflict with the rest of the advice. I hope the formulation above > is also okay. It is based on the new wording from you and Dick in first > part of the proposal. > > Best regards > Rolf > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. *

1 0

Re: [mpi-21] Ballot 4 - Re: Request for interpretation
by unknown＠example.com 31 Jan '08

31 Jan '08

Your wording works for me Rolf. -- Thanks Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-21-bounces_at_[hidden] wrote on 01/31/2008 05:25:46 AM: > I try to summarize all 3 replies in one proposal: > > ___________________________________ > > Proposal: > MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38-40 read: > If a function does not recognize a key, > it will ignore it, unless otherwise specified. > If an implementation recognizes a key but does not recognize > the format of the corresponding value, the result is undefined. > but should read: > An implementation must support info objects as caches for arbitrary > (key, value) pairs, regardless of whether it recognizes the pairs. > Each MPI function which takes hints in the form of an MPI_Info must > be prepared to ignore any key it does not recognize. > > Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new > paragraph: > Advice to implementors. > Although in MPI functions that take hints in form of an MPI_Info > (e.g., in process creation and management, one-sided communication, > or parallel file I/O), an implementation must be prepared to ignore > keys that it does not recognize, for the purpose of MPI_INFO_GET_NKEYS, > MPI_INFO_GET_NTHKEY, MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the > implementation must retain all (key,value) pairs so that layered > functionality can also use the Info object. > (End of advice to implementors.) > _____________________________ > Rationale for this clarification: > > The MPI-2.0 text allowed that also MPI_INFO_DELETE, MPI_INFO_SET, > MPI_INFO_GET, and MPI_INFO_DUP could ignore (key,value) pairs > that are not recognized in routines in other chapters that > take hints with info arguments. > The proposed clarification is necessary when we assume, that > layered implementation of parts of the MPI-2 standard should > be possible and may use the MPI_Info objects for their needs. > This was a goal of the MPI-2 Forum and the MPI-2.0 specification. > ___________________________________ > > Bronis, for me, your wording "an MPI implementation may restrict" was > in conflict with the rest of the advice. I hope the formulation above > is also okay. It is based on the new wording from you and Dick in first > part of the proposal. > > Best regards > Rolf > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 *

1 0

Ballot 4 - MPI_File_set_info update or replacement
by unknown＠example.com 31 Jan '08

31 Jan '08

This is a proposal for MPI 2.1, Ballot 4. I'm asking especially the implementors to check, whether this interpretation is implemented in their MPI implementations, or does not contradict to the existing implementation. This is a follow up to: MPI_File_set_info in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… with mail discussion not yet existing ___________________________________ Proposal: Add in MPI-2.0 Sect. 9.2.8, File Info, page 218, after line 18 the following sentences: With MPI_FILE_SET_VIEW and MPI_FILE_SET_INFO the current setting of all hints used by the system to this open file is updated by the (key,value) pairs in the info argument. ___________________________________ Rationale for this clarification: This text was missing. It was not clear, whether a info handles in MPI_FILE_SET_VIEW and MPI_FILE_SET_INFO are updating or replacing the current set of used hints. The developers from ROMIO decided to update the current set of used hints. Therefore, this behavior should be the expected behavior of a majority of users. ___________________________________ Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Ballot 4 - MPI_File_get_info
by unknown＠example.com 31 Jan '08

31 Jan '08

This is a proposal for MPI 2.1, Ballot 4. I'm asking especially the implementors to check, whether this interpretation is implemented in their MPI implementations, or does not contradict to the existing implementation. This is a follow up to: MPI_File_get_info in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… with mail discussion not yet existing ___________________________________ Proposal: MPI-2.0 Sect. 9.2.8, File Info, page 219, lines 11-13 read: MPI_FILE_GET_INFO returns a new info object containing the hints of the file associated with fh. The current setting of all hints actually used by the system related to this open file is returned in info_used. The user is responsible for freeing info_used via MPI_INFO_FREE. but should read (" or an abort(errorcode)" removed): MPI_FILE_GET_INFO returns a new info object containing the hints of the file associated with fh. The current setting of all hints actually used by the system related to this open file is returned in info_used. If there does not exist such a hint, MPI_INFO_NULL is returned. The user is responsible for freeing info_used via MPI_INFO_FREE if info_used is not MPI_INFO_NULL. ___________________________________ Rationale for this clarification: This text was missing. It was not clear, whether a MPI_Info handle would be returned that would return nkeys=0 from MPI_INFO_GET_NKEYS. From user's point of view, this behavior might have been expected without this clarification. ___________________________________ As far as I understand, ROMIO is using for all filesystems some default hints and therefore "no-hints" is never returned. MPI_File_set_view and MPI_File_set_info are only modifying values but do not remove keys. Therefore, the info handle cannot become empty. Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0