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

Re: [mpi-21] Handling errors in handle transfer functions
by unknown＠example.com 31 Jan '08

31 Jan '08

No clarification needed is still my take on it 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 11:24:25 AM: > Mainly to Bill Gropp, Dick Treumann, and Marc Snir, > who have contributed to this mail-discussion thread. > > This is a follow up to: > Reporting invalid handles provided to handle conversion functions > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/index.html > with mail discussion in > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/discuss/handleerrors/ > > _________________________________________ > > When I understand correctly, then a clarification is not needed > in the MPI standard. > > If somebody wants a clarification to be included into the standard > and therefore in Ballot 4, please send me your wording > with the page and line references included. > > If all agree, that no clarification is needed, then I would finish > this discussion-thread. > > 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 - MPI_THREAD_FUNNELED - was Re: Attending, topics, etc
by unknown＠example.com 31 Jan '08

31 Jan '08

What is the definition of a "main thread" ? The OpenMP example is still vague. I think we should clarify what we expect the "main thread" to be. From my perspective, this "main thread" is the one that called the MPI_Init_thread function, as the MPI library is then allowed to attach some kind of private key(s) to it (pthread_key_create). Thanks, george. On Jan 31, 2008, at 11:09 AM, Rolf Rabenseifner wrote: > Sorry Rich, > > but MPI 2.0 has defined "main thread", and not less! > > The open question was only, who is responsible for guaranteing this. > > Dicks text is fine: >>> MPI_THREAD_FUNNELED The process may be multi-threaded, but the >>> application >>> must insure that only the main thread makes MPI calls. > > My first proposal >>>>>>> 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). > has the advantage, that "main thread" is defined by refering to > the OpenMP-Standard where "OpenMP master thread" is defined (and not > "main"). > > We can combine this to: > MPI_THREAD_FUNNELED The process may be multi-threaded, but the > application > must insure that only the main thread makes MPI calls, e.g., by > using the > OpenMP directive "master". > > (This clearly tells that OpenMP single directive is not enough.) > > Best regards > Rolf > > > On Thu, 31 Jan 2008 10:50:35 -0500 > Richard Graham <rlgraham_at_[hidden]> wrote: >> Why restrict this to a standard specified thread (main thread), why >> not word >> it >> as a singe thread, and let the app decide what thread this is, >> based on >> what >> ever criteria it wants to use to select this thread ? >> >> Rich >> >> >> On 1/31/08 10:27 AM, "Richard Treumann" <treumann_at_[hidden]> wrote: >> >>> How about:: >>> MPI_THREAD_FUNNELED The process may be multi-threaded, but the >>> application >>> must insure that only the main thread makes MPI calls. >>> >>> >>> 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 09:44:08 AM: >>> >>>>> A simpler change which would seem to achieve the desired >>>>> clarification >>>>> would be :- >>>>> >>>>> MPI_THREAD_FUNNELED The process may be multi-threaded, but >>>>> only the >>>>> main >>>>> thread is allowed to make MPI calls. >>>>> >>>>> (and you could add >>>>> If other threads make MPI calls the behavior is undefined. >>>>> if you want to be verbose about it). >>>>> >>>>> -- Jim >>>>> >>>>> James Cownie <james.h.cownie_at_[hidden]> >>>>> SSG/DPD/PAT >>>>> Tel: +44 117 9071438 >>>>> >>>>> >>>>> >>>>> >>>>>>> -----Original Message----- >>>>>>> From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden] >>>>>>> ] >>>>> On >>>>>>> Behalf Of Rolf Rabenseifner >>>>>>> Sent: 31 January 2008 14:31 >>>>>>> To: mpi-21_at_[hidden] >>>>>>> Subject: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: >>>>>>> Attending, >>>>>>> topics, etc >>>>>>> >>>>>>> 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.html >>>>>>> with mail discussion in >>>>>>> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- >>>>>>> errata/discuss/funneled/ >>>>>>> ___________________________________ >>>>>>> >>>>>>> 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) >>>>>>> _______________________________________________ >>>>>>> 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 >>> >>> >>> _______________________________________________ >>> 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) > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 *

1 0

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

31 Jan '08

Jim and Rich: Then I suggest that fixing this broken semantic decision is something that we should consider for MPI 2.2. It should not break any existing programs and might even make some existing ones standards conforming. Although I can imagine ways for the MPI implementation to detect that the one thread is not the main thread it is not at all clear to me how it would matter to the implementation. Bronis On Thu, 31 Jan 2008, Cownie, James H wrote: > Because that's how it's always been. We're not adding a restriction with > the change, merely clarifying the existing restriction. > > -- 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 Graham > Sent: 31 January 2008 15:51 > To: Mailing list for discussion of MPI 2.1 > Subject: Re: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: > Attending, topics, etc > > > > Why restrict this to a standard specified thread (main thread), why not > word it > as a singe thread, and let the app decide what thread this is, based on > what > ever criteria it wants to use to select this thread ? > > Rich > > > On 1/31/08 10:27 AM, "Richard Treumann" <treumann_at_[hidden]> wrote: > > How about:: > MPI_THREAD_FUNNELED The process may be multi-threaded, but the > application > must insure that only the main thread makes MPI calls. > > > 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 09:44:08 AM: > > > A simpler change which would seem to achieve the desired clarification > > would be :- > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only the > > main > > thread is allowed to make MPI calls. > > > > (and you could add > > If other threads make MPI calls the behavior is undefined. > > if you want to be verbose about it). > > > > -- Jim > > > > James Cownie <james.h.cownie_at_[hidden]> > > SSG/DPD/PAT > > Tel: +44 117 9071438 > > > > > > > > > > > -----Original Message----- > > > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] > <mailto:mpi-21-bounces_at_[hidden]%5d> > > On > > > Behalf Of Rolf Rabenseifner > > > Sent: 31 January 2008 14:31 > > > To: mpi-21_at_[hidden] > > > Subject: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: > Attending, > > > topics, etc > > > > > > 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.html > > > with mail discussion in > > > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > > > errata/discuss/funneled/ > > > ___________________________________ > > > > > > 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) > > > _______________________________________________ > > > 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 > > ________________________________ > > _______________________________________________ > 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 - User defined datarep - was Re: Question toMPI/IO
by unknown＠example.com 31 Jan '08

31 Jan '08

> Then in subsequent calls to the conversion function, > MPI will increment the value in position by the count of items > converted in the previous call, and userbuf is kept unchanged. Maybe we should be more clear and say that "the userbuf pointer is left unchanged" Rajeev > -----Original Message----- > From: mpi-21-bounces_at_[hidden] > [mailto:mpi-21-bounces_at_[hidden]] On Behalf Of Rolf Rabenseifner > Sent: Thursday, January 31, 2008 10:49 AM > To: mpi-21_at_[hidden] > Subject: [mpi-21] Ballot 4 - User defined datarep - was Re: > Question toMPI/IO > > This is a proposal for MPI 2.1, Ballot 4. > > I'm asking especially > Hubert Ritzdorf, Jean-Pierre Prost, John May, Bill Nitzberg, > the participants of the email-discussion in 1999, to review > this proposal. > > This is a follow up to: > Interpretation of user defined datarep > in > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/index.html > with mail discussion in > > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/discuss/datarep/ > ___________________________________ > > Proposal: > MPI-2.0 Sect. 9.5.3 User-defined Data Representations, page 254, > lines 13-15 read: > Then in subsequent calls to the conversion function, > MPI will increment the value in position by the count of items > converted in the previous call. > > but should read: > Then in subsequent calls to the conversion function, > MPI will increment the value in position by the count of items > converted in the previous call, and userbuf is kept unchanged. > > ___________________________________ > Rationale for this clarification: > It was not clear, whether the userbuf pointer must also be moved > in the subsequent calls. This clarification was already done in > 1999 and should already be implemented in existing implementations > of user-defined data representations. > ___________________________________ > Total text page 254 lines 8-15: > If MPI cannot allocate a buffer large enough to hold all the > data to be converted from a read operation, it may call the > conversion function repeatedly using the same datatype and > userbuf, and reading successive chunks of data to be converted > in filebuf. For the first call (and in the case when all the data > to be converted fits into filebuf), MPI will call the function > with position set to zero. Data converted during this call will > be stored in the userbuf according to the first count data items > in datatype. Then in subsequent calls to the conversion function, > MPI will increment the value in position by the count of items > converted in the previous call, > (new text added:) > and userbuf is kept unchanged. > ___________________________________ > > 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 - MPI_File_set_info update or replacement
by unknown＠example.com 31 Jan '08

31 Jan '08

The intent is that if the user calls MPI_File_set_info (or MPI_File_set_view) twice, the 2nd call will only update (if possible) the key-vals passed in the 2nd call; others are unmodified. If the 2nd call passes MPI_INFO_NULL, nothing will change -- it won't nullify previously passed hints. Rajeev _____ From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] On Behalf Of Richard Treumann Sent: Thursday, January 31, 2008 9:23 AM To: Mailing list for discussion of MPI 2.1 Subject: Re: [mpi-21] Ballot 4 - MPI_File_set_info update or replacement I think we have an overall ambiguity about what the "current set of hints" is. This ambiguity is evident in the question about what MPI_FILE_INFO_GET returns and in this discussion too. If an implementation supports 5 file hints then it must select a value for each of these hints an MPI_FILE_OPEN. If there is an MPI_Info that stipulates 2 of the hints then how many hints are in the "current set of hints"? 2 or 5? I would say there are 5 and I think it makes sense for MPI_FILE_GET_INFO to return all 5 (key,value) pairs. Two more specific points - 1) I would expect that if at MPI_FILE_OPEN the implementation is given non-default hints ("A","yes") and ("B","no") and then at MPI_FILE_INFO_SET is given ("B","yes") the net effect is that hint "A" remains as set and hint "B" is altered (if possible). If there is a hint "C" which has never been mentioned it will have received a default value at MPI_FILE_OPEN and the MPI_FILE_INFO_SET which does not mention "C" will leave that default unchanged. Is the "clarification" saying hint "A" must return to default when MPI_FILE_INFO_SET fails to mention it? If that is the intent then I need to be convinced. If we decide this is to be blessed then we probably need to say that any use of MPI_FILE_SET_INFO must first call MPI_FILE_GET_INFO, tweek the INFO it gets back from MPI_FILE_GET_INFO and pass that to MPI_FILE_SET_INFO to avoid unexpected changes to the set of hints that is "in effect". 2) Since a hint is a hint, not a command, it can be rejected. It is possible that some hint can be honored at MPI_FILE_OPEN but once it has been honored, cannot be altered at reasonable cost. For example, maybe somebody's MPI_FILE_OPEN could accept a hint ("buffer_size", "dynamic-64MB") meaning "start with a 64MB buffer but be prepared to accept changes to buffer size". If the user has set hint ("buffer_size", "64MB") at FILE_OPEN, the implelentation would omit whatever synchs are needed to preserve the ability to change on the fly. Passing ("buffer_size", "dynamic-16MB") to MPI_FILE_SET_INFO could be honored if the user had chosen "dynamic" at FILE_OPEN but would need to be ignored if he had not. For most implementations, a hint like "buffer_size" could not be honored at all after the first file read or write had been done. 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:24:51 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_set_info > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/index.html > 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) > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 *

1 0

Re: [mpi-21] Correction to One-sided communications, Section 6.7: Semantics and Correctness
by unknown＠example.com 31 Jan '08

31 Jan '08

Dear all, I'm asking especially Jesper Traeff, Rajeev Thakur, and Dick Treumann, the participants of the email-discussion in 2003 for a proposal: Please can you all look, whether a clarification or correction is really needed and such a proposal would be a consensus. Please, if you make a proposal, clearly specify the page and line numbers. If it is done now, it may go into MPI 2.1, Ballot 4. ___________________________________ This is a follow up to: Are MPI_Win_wait and MPI_Win_post interchanged in the discussion of one-sided completion? 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… ___________________________________ Thank you and 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

Exactly one of MPI_MODE_RDONLY, MPI_MODE_RDWR, MPI_MODE_WRONLY
by unknown＠example.com 31 Jan '08

31 Jan '08

I'm removing the question MPI_MODE_RDONLY, MPI_MODE_RDWR, MPI_MODE_WRONLY Is it an error to specify more than one of these? from the errata page, because MPI-2.0, Sect. 9.2.1, page 213 lines 3-4 read: Exactly one of MPI MODE RDONLY, MPI MODE RDWR, or MPI MODE WRONLY, must be specified. This means, the question is already fully answered. And there seems not to be any mail discussion on this topic. Was there any mail (not on the Forum reflector) asking this? If yes, this mail might be forwarded to the questioner. 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 - User defined datarep - was Re: Question to MPI/IO
by unknown＠example.com 31 Jan '08

31 Jan '08

This is a proposal for MPI 2.1, Ballot 4. I'm asking especially Hubert Ritzdorf, Jean-Pierre Prost, John May, Bill Nitzberg, the participants of the email-discussion in 1999, to review this proposal. This is a follow up to: Interpretation of user defined datarep 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. 9.5.3 User-defined Data Representations, page 254, lines 13-15 read: Then in subsequent calls to the conversion function, MPI will increment the value in position by the count of items converted in the previous call. but should read: Then in subsequent calls to the conversion function, MPI will increment the value in position by the count of items converted in the previous call, and userbuf is kept unchanged. ___________________________________ Rationale for this clarification: It was not clear, whether the userbuf pointer must also be moved in the subsequent calls. This clarification was already done in 1999 and should already be implemented in existing implementations of user-defined data representations. ___________________________________ Total text page 254 lines 8-15: If MPI cannot allocate a buffer large enough to hold all the data to be converted from a read operation, it may call the conversion function repeatedly using the same datatype and userbuf, and reading successive chunks of data to be converted in filebuf. For the first call (and in the case when all the data to be converted fits into filebuf), MPI will call the function with position set to zero. Data converted during this call will be stored in the userbuf according to the first count data items in datatype. Then in subsequent calls to the conversion function, MPI will increment the value in position by the count of items converted in the previous call, (new text added:) and userbuf is kept unchanged. ___________________________________ 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] Handling errors in handle transfer functions
by unknown＠example.com 31 Jan '08

31 Jan '08

Mainly to Bill Gropp, Dick Treumann, and Marc Snir, who have contributed to this mail-discussion thread. This is a follow up to: Reporting invalid handles provided to handle conversion functions 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… _________________________________________ When I understand correctly, then a clarification is not needed in the MPI standard. If somebody wants a clarification to be included into the standard and therefore in Ballot 4, please send me your wording with the page and line references included. If all agree, that no clarification is needed, then I would finish this discussion-thread. 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_THREAD_FUNNELED - was Re: Attending, topics, etc
by unknown＠example.com 31 Jan '08

31 Jan '08

Sorry Rich, but MPI 2.0 has defined "main thread", and not less! The open question was only, who is responsible for guaranteing this. Dicks text is fine: >> MPI_THREAD_FUNNELED The process may be multi-threaded, but the application >> must insure that only the main thread makes MPI calls. My first proposal >>>> > > 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). has the advantage, that "main thread" is defined by refering to the OpenMP-Standard where "OpenMP master thread" is defined (and not "main"). We can combine this to: MPI_THREAD_FUNNELED The process may be multi-threaded, but the application must insure that only the main thread makes MPI calls, e.g., by using the OpenMP directive "master". (This clearly tells that OpenMP single directive is not enough.) Best regards Rolf On Thu, 31 Jan 2008 10:50:35 -0500 Richard Graham <rlgraham_at_[hidden]> wrote: >Why restrict this to a standard specified thread (main thread), why not word >it > as a singe thread, and let the app decide what thread this is, based on >what > ever criteria it wants to use to select this thread ? > >Rich > > >On 1/31/08 10:27 AM, "Richard Treumann" <treumann_at_[hidden]> wrote: > >> How about:: >> MPI_THREAD_FUNNELED The process may be multi-threaded, but the application >> must insure that only the main thread makes MPI calls. >> >> >> 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 09:44:08 AM: >> >>> > A simpler change which would seem to achieve the desired clarification >>> > would be :- >>> > >>> > MPI_THREAD_FUNNELED The process may be multi-threaded, but only the >>> > main >>> > thread is allowed to make MPI calls. >>> > >>> > (and you could add >>> > If other threads make MPI calls the behavior is undefined. >>> > if you want to be verbose about it). >>> > >>> > -- Jim >>> > >>> > James Cownie <james.h.cownie_at_[hidden]> >>> > SSG/DPD/PAT >>> > Tel: +44 117 9071438 >>> > >>> > >>> > >>> > >>>> > > -----Original Message----- >>>> > > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] >>> > On >>>> > > Behalf Of Rolf Rabenseifner >>>> > > Sent: 31 January 2008 14:31 >>>> > > To: mpi-21_at_[hidden] >>>> > > Subject: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: Attending, >>>> > > topics, etc >>>> > > >>>> > > 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.html >>>> > > with mail discussion in >>>> > > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- >>>> > > errata/discuss/funneled/ >>>> > > ___________________________________ >>>> > > >>>> > > 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) >>>> > > _______________________________________________ >>>> > > 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 >> >> >> _______________________________________________ >> 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