March 2015 - mpiwg-hybridpm - mailman3.cels.anl.gov

Re: [mpiwg-hybridpm] Changes to the EI chapter
by Jeff Hammond 03 Mar '15

03 Mar '15

On Tue, Mar 3, 2015 at 3:48 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > On Mar 3, 2015, at 3:46 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> >>> Not linking against pthreads doesn't mean anything -- every process still has at least 1 thread. >> >> You are making the semantic link between an OS process and a thread in >> CS lexicon. That's really not helpful here. > > It's a fact: every process, even every MPI process, has at least 1 thread. > > How is that wrong? It is a logical tautology. It is not a useful contribution to this discussion. >>> That was the whole point of the ticket: these functions are *always* thread safe. >>> >>> ...which is what Jeff Hammond wanted. :-) >> >> Then we are requiring ALL implementations to support threads. You >> want to make that rather huge change to MPI as part of dickering over >> this sentence? > > Ok, I'm lost. You wanted this ticket. You started this ticket. You pushed for this ticket. Yes, and I expect that an implementation that supports threads in the most basic sense of the word, which means that it is theoretically possible that an implementation can return provided>MPI_THREAD_SINGLE, that it be possible to determine what provided is without causing the program to be invalid. If an implementation is incapable by design and documentation to return provided>MPI_THREAD_SINGLE because it has taken the lame path of not supporting user threads beyond those that run "int main()", then it is impossible for us to ask them to support this feature. > Now you don't want it any more? See above. -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-hybridpm] Changes to the EI chapter
by Jeff Squyres (jsquyres) 03 Mar '15

03 Mar '15

*This thread* is meaningless. :-) We're in the same room and emailing flames at each other. Let's talk after the session. > On Mar 3, 2015, at 3:47 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > The text means exactly what it means. How much more pedantic does it > need to be? > > On Tue, Mar 3, 2015 at 3:43 PM, Jeff Squyres (jsquyres) > <jsquyres(a)cisco.com> wrote: >> It's removed because it's ambiguous/meaningless. If you want to state something specific, state something specific. >> >> >>> On Mar 3, 2015, at 3:40 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>> >>> I wrote the primary wording. Ball is in your court to propose an >>> alternative if you don't like my version. But it has to preserve the >>> intent of the original text, not just remove it because it makes you >>> uncomfortable. >>> >>> Jeff >>> >>> On Tue, Mar 3, 2015 at 3:38 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>> >>>> Please suggest alternate wording. >>>> >>>> -- Pavan >>>> >>>>> On Mar 3, 2015, at 5:32 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>>>> >>>>> I could be wrong, but if I wrote that sentence, I meant what George >>>>> said and not anything else. >>>>> >>>>> Jeff >>>>> >>>>> On Tue, Mar 3, 2015 at 3:24 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>>>> >>>>>> This was not what was voted on. The vote was based on the PDF, which doesn't contain this text. So the change is incorrect and comes under the chapter committee prerogative. >>>>>> >>>>>> Coming to the change itself, for environments that don't even allow multiple threads to exist, this is trivial for MPI implementations to provide. The concern is that before MPI_INIT_THREAD, I do not know if I can use THREAD_MULTIPLE or not. The user does not know and should be able to call these functions either way. >>>>>> >>>>>> -- Pavan >>>>>> >>>>>>> On Mar 3, 2015, at 4:56 PM, George Bosilca <bosilca(a)icl.utk.edu> wrote: >>>>>>> >>>>>>> This change is a direct effect of the #357 ticket (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/357) that has been discussed and had received a successful vote (18 yes, 0 no, 1 abstain). >>>>>>> >>>>>>> Removing this particular part of the paragraph does not clarify all conflicts of this section. Few lines above there is an even bolder statement claiming that "Therefore, \MPI/ implementations are not required to be thread compliant as defined in this section." So to thread or not to thread? >>>>>>> >>>>>>> My understanding is that "implementation that do not support threads" are not referring to implementations that solely provide support for MPI_THREAD_SERIALIZED, but to implementations that have no thread support at all (they don't even link against pthreads). Forcing such an implementation to provide thread safety for a handful of functions is unreasonable. >>>>>>> >>>>>>> George. >>>>>>> >>>>>>> >>>>>>> On Tue, Mar 3, 2015 at 5:30 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>>>>> >>>>>>> Thanks. Jim/Jeff/Aurelien? >>>>>>> >>>>>>>> On Mar 3, 2015, at 4:29 PM, Daniel Holmes <dholmes(a)epcc.ed.ac.uk> wrote: >>>>>>>> >>>>>>>> I agree that this sentence should not be in the standard. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Dan. >>>>>>>> >>>>>>>> On 03/03/2015 14:24, Balaji, Pavan wrote: >>>>>>>>> The Forum was not entirely happy with the chapter committee change on the EI chapter. Specifically, the following sentence that was added into the pdf should be removed: >>>>>>>>> >>>>>>>>> "Implementations that do not support threads are not required to support the calling of these functions from threads." >>>>>>>>> >>>>>>>>> This is in direct contradiction to the fact that the mentioned functions should work correctly without knowing whether threads are there or not. I plan to remove it. Please let me know what you think. >>>>>>>>> >>>>>>>>> -- Pavan >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Pavan Balaji ✉️ >>>>>>>>> http://www.mcs.anl.gov/~balaji >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> mpiwg-hybridpm mailing list >>>>>>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>>>>>> >>>>>>>> -- >>>>>>>> Dan Holmes >>>>>>>> Applications Consultant in HPC Research >>>>>>>> EPCC, The University of Edinburgh >>>>>>>> James Clerk Maxwell Building >>>>>>>> The Kings Buildings >>>>>>>> Peter Guthrie Tait Road >>>>>>>> Edinburgh >>>>>>>> EH9 3FD >>>>>>>> T: +44(0)131 651 3465 >>>>>>>> E: dholmes(a)epcc.ed.ac.uk >>>>>>>> >>>>>>>> *Please consider the environment before printing this email.* >>>>>>>> >>>>>>>> >>>>>>>> The University of Edinburgh is a charitable body, registered in >>>>>>>> Scotland, with registration number SC005336. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mpiwg-hybridpm mailing list >>>>>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>>>>> >>>>>>> -- >>>>>>> Pavan Balaji ✉️ >>>>>>> http://www.mcs.anl.gov/~balaji >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mpiwg-hybridpm mailing list >>>>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mpiwg-hybridpm mailing list >>>>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>>>> >>>>>> -- >>>>>> Pavan Balaji ✉️ >>>>>> http://www.mcs.anl.gov/~balaji >>>>>> >>>>>> _______________________________________________ >>>>>> mpiwg-hybridpm mailing list >>>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>>> >>>>> >>>>> >>>>> -- >>>>> Jeff Hammond >>>>> jeff.science(a)gmail.com >>>>> http://jeffhammond.github.io/ >>>>> _______________________________________________ >>>>> mpiwg-hybridpm mailing list >>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>> >>>> -- >>>> Pavan Balaji ✉️ >>>> http://www.mcs.anl.gov/~balaji >>>> >>>> _______________________________________________ >>>> mpiwg-hybridpm mailing list >>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>> >>> >>> >>> -- >>> Jeff Hammond >>> jeff.science(a)gmail.com >>> http://jeffhammond.github.io/ >>> _______________________________________________ >>> mpiwg-hybridpm mailing list >>> mpiwg-hybridpm(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpiwg-hybridpm mailing list >> mpiwg-hybridpm(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > mpiwg-hybridpm mailing list > mpiwg-hybridpm(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpiwg-hybridpm] Changes to the EI chapter
by Jeff Squyres (jsquyres) 03 Mar '15

03 Mar '15

On Mar 3, 2015, at 3:46 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > >> Not linking against pthreads doesn't mean anything -- every process still has at least 1 thread. > > You are making the semantic link between an OS process and a thread in > CS lexicon. That's really not helpful here. It's a fact: every process, even every MPI process, has at least 1 thread. How is that wrong? >> That was the whole point of the ticket: these functions are *always* thread safe. >> >> ...which is what Jeff Hammond wanted. :-) > > Then we are requiring ALL implementations to support threads. You > want to make that rather huge change to MPI as part of dickering over > this sentence? Ok, I'm lost. You wanted this ticket. You started this ticket. You pushed for this ticket. Now you don't want it any more? -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpiwg-hybridpm] Changes to the EI chapter
by Jeff Hammond 03 Mar '15

03 Mar '15

On Tue, Mar 3, 2015 at 3:44 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > >> On Mar 3, 2015, at 5:42 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >>> My understanding is that "implementation that do not support threads" are not referring to implementations that solely provide support for MPI_THREAD_SERIALIZED, >> >> Where is that defined? This is a question that came out of the forum: "What exactly does it mean to 'not support threads'? Every process has at least one thread." > > Lines 13-14: > > MPI may be implemented in environ- ments where threads are not supported or perform poorly. EXACTLY. Unless we strike this text, we need my sentence. -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-hybridpm] Changes to the EI chapter
by Jeff Hammond 03 Mar '15

03 Mar '15

The text means exactly what it means. How much more pedantic does it need to be? On Tue, Mar 3, 2015 at 3:43 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > It's removed because it's ambiguous/meaningless. If you want to state something specific, state something specific. > > >> On Mar 3, 2015, at 3:40 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> >> I wrote the primary wording. Ball is in your court to propose an >> alternative if you don't like my version. But it has to preserve the >> intent of the original text, not just remove it because it makes you >> uncomfortable. >> >> Jeff >> >> On Tue, Mar 3, 2015 at 3:38 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>> >>> Please suggest alternate wording. >>> >>> -- Pavan >>> >>>> On Mar 3, 2015, at 5:32 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>>> >>>> I could be wrong, but if I wrote that sentence, I meant what George >>>> said and not anything else. >>>> >>>> Jeff >>>> >>>> On Tue, Mar 3, 2015 at 3:24 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>>> >>>>> This was not what was voted on. The vote was based on the PDF, which doesn't contain this text. So the change is incorrect and comes under the chapter committee prerogative. >>>>> >>>>> Coming to the change itself, for environments that don't even allow multiple threads to exist, this is trivial for MPI implementations to provide. The concern is that before MPI_INIT_THREAD, I do not know if I can use THREAD_MULTIPLE or not. The user does not know and should be able to call these functions either way. >>>>> >>>>> -- Pavan >>>>> >>>>>> On Mar 3, 2015, at 4:56 PM, George Bosilca <bosilca(a)icl.utk.edu> wrote: >>>>>> >>>>>> This change is a direct effect of the #357 ticket (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/357) that has been discussed and had received a successful vote (18 yes, 0 no, 1 abstain). >>>>>> >>>>>> Removing this particular part of the paragraph does not clarify all conflicts of this section. Few lines above there is an even bolder statement claiming that "Therefore, \MPI/ implementations are not required to be thread compliant as defined in this section." So to thread or not to thread? >>>>>> >>>>>> My understanding is that "implementation that do not support threads" are not referring to implementations that solely provide support for MPI_THREAD_SERIALIZED, but to implementations that have no thread support at all (they don't even link against pthreads). Forcing such an implementation to provide thread safety for a handful of functions is unreasonable. >>>>>> >>>>>> George. >>>>>> >>>>>> >>>>>> On Tue, Mar 3, 2015 at 5:30 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>>>> >>>>>> Thanks. Jim/Jeff/Aurelien? >>>>>> >>>>>>> On Mar 3, 2015, at 4:29 PM, Daniel Holmes <dholmes(a)epcc.ed.ac.uk> wrote: >>>>>>> >>>>>>> I agree that this sentence should not be in the standard. >>>>>>> >>>>>>> Cheers, >>>>>>> Dan. >>>>>>> >>>>>>> On 03/03/2015 14:24, Balaji, Pavan wrote: >>>>>>>> The Forum was not entirely happy with the chapter committee change on the EI chapter. Specifically, the following sentence that was added into the pdf should be removed: >>>>>>>> >>>>>>>> "Implementations that do not support threads are not required to support the calling of these functions from threads." >>>>>>>> >>>>>>>> This is in direct contradiction to the fact that the mentioned functions should work correctly without knowing whether threads are there or not. I plan to remove it. Please let me know what you think. >>>>>>>> >>>>>>>> -- Pavan >>>>>>>> >>>>>>>> -- >>>>>>>> Pavan Balaji ✉️ >>>>>>>> http://www.mcs.anl.gov/~balaji >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mpiwg-hybridpm mailing list >>>>>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>>>>> >>>>>>> -- >>>>>>> Dan Holmes >>>>>>> Applications Consultant in HPC Research >>>>>>> EPCC, The University of Edinburgh >>>>>>> James Clerk Maxwell Building >>>>>>> The Kings Buildings >>>>>>> Peter Guthrie Tait Road >>>>>>> Edinburgh >>>>>>> EH9 3FD >>>>>>> T: +44(0)131 651 3465 >>>>>>> E: dholmes(a)epcc.ed.ac.uk >>>>>>> >>>>>>> *Please consider the environment before printing this email.* >>>>>>> >>>>>>> >>>>>>> The University of Edinburgh is a charitable body, registered in >>>>>>> Scotland, with registration number SC005336. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mpiwg-hybridpm mailing list >>>>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>>>> >>>>>> -- >>>>>> Pavan Balaji ✉️ >>>>>> http://www.mcs.anl.gov/~balaji >>>>>> >>>>>> _______________________________________________ >>>>>> mpiwg-hybridpm mailing list >>>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>>>> >>>>>> _______________________________________________ >>>>>> mpiwg-hybridpm mailing list >>>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>>> >>>>> -- >>>>> Pavan Balaji ✉️ >>>>> http://www.mcs.anl.gov/~balaji >>>>> >>>>> _______________________________________________ >>>>> mpiwg-hybridpm mailing list >>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>> >>>> >>>> >>>> -- >>>> Jeff Hammond >>>> jeff.science(a)gmail.com >>>> http://jeffhammond.github.io/ >>>> _______________________________________________ >>>> mpiwg-hybridpm mailing list >>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>> >>> -- >>> Pavan Balaji ✉️ >>> http://www.mcs.anl.gov/~balaji >>> >>> _______________________________________________ >>> mpiwg-hybridpm mailing list >>> mpiwg-hybridpm(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >> >> >> >> -- >> Jeff Hammond >> jeff.science(a)gmail.com >> http://jeffhammond.github.io/ >> _______________________________________________ >> mpiwg-hybridpm mailing list >> mpiwg-hybridpm(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-hybridpm mailing list > mpiwg-hybridpm(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-hybridpm] Changes to the EI chapter
by Jeff Hammond 03 Mar '15

03 Mar '15

On Tue, Mar 3, 2015 at 3:42 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > On Mar 3, 2015, at 2:56 PM, George Bosilca <bosilca(a)icl.utk.edu> wrote: >> >> This change is a direct effect of the #357 ticket (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/357) that has been discussed and had received a successful vote (18 yes, 0 no, 1 abstain). >> >> Removing this particular part of the paragraph does not clarify all conflicts of this section. Few lines above there is an even bolder statement claiming that "Therefore, \MPI/ implementations are not required to be thread compliant as defined in this section." So to thread or not to thread? >> >> My understanding is that "implementation that do not support threads" are not referring to implementations that solely provide support for MPI_THREAD_SERIALIZED, > > Where is that defined? This is a question that came out of the forum: "What exactly does it mean to 'not support threads'? Every process has at least one thread." Ugh. Seriously? MPI-1 "did not support threads". It's pretty obvious. >> but to implementations that have no thread support at all (they don't even link against pthreads). > > Not linking against pthreads doesn't mean anything -- every process still has at least 1 thread. You are making the semantic link between an OS process and a thread in CS lexicon. That's really not helpful here. >> Forcing such an implementation to provide thread safety for a handful of functions is unreasonable. > > That was the whole point of the ticket: these functions are *always* thread safe. > > ...which is what Jeff Hammond wanted. :-) Then we are requiring ALL implementations to support threads. You want to make that rather huge change to MPI as part of dickering over this sentence? -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-hybridpm] Changes to the EI chapter
by Balaji, Pavan 03 Mar '15

03 Mar '15

> On Mar 3, 2015, at 5:42 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >> My understanding is that "implementation that do not support threads" are not referring to implementations that solely provide support for MPI_THREAD_SERIALIZED, > > Where is that defined? This is a question that came out of the forum: "What exactly does it mean to 'not support threads'? Every process has at least one thread." Lines 13-14: MPI may be implemented in environ- ments where threads are not supported or perform poorly. -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

1 0

Re: [mpiwg-hybridpm] Changes to the EI chapter
by Jeff Squyres (jsquyres) 03 Mar '15

03 Mar '15

It's removed because it's ambiguous/meaningless. If you want to state something specific, state something specific. > On Mar 3, 2015, at 3:40 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > I wrote the primary wording. Ball is in your court to propose an > alternative if you don't like my version. But it has to preserve the > intent of the original text, not just remove it because it makes you > uncomfortable. > > Jeff > > On Tue, Mar 3, 2015 at 3:38 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >> Please suggest alternate wording. >> >> -- Pavan >> >>> On Mar 3, 2015, at 5:32 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>> >>> I could be wrong, but if I wrote that sentence, I meant what George >>> said and not anything else. >>> >>> Jeff >>> >>> On Tue, Mar 3, 2015 at 3:24 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>> >>>> This was not what was voted on. The vote was based on the PDF, which doesn't contain this text. So the change is incorrect and comes under the chapter committee prerogative. >>>> >>>> Coming to the change itself, for environments that don't even allow multiple threads to exist, this is trivial for MPI implementations to provide. The concern is that before MPI_INIT_THREAD, I do not know if I can use THREAD_MULTIPLE or not. The user does not know and should be able to call these functions either way. >>>> >>>> -- Pavan >>>> >>>>> On Mar 3, 2015, at 4:56 PM, George Bosilca <bosilca(a)icl.utk.edu> wrote: >>>>> >>>>> This change is a direct effect of the #357 ticket (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/357) that has been discussed and had received a successful vote (18 yes, 0 no, 1 abstain). >>>>> >>>>> Removing this particular part of the paragraph does not clarify all conflicts of this section. Few lines above there is an even bolder statement claiming that "Therefore, \MPI/ implementations are not required to be thread compliant as defined in this section." So to thread or not to thread? >>>>> >>>>> My understanding is that "implementation that do not support threads" are not referring to implementations that solely provide support for MPI_THREAD_SERIALIZED, but to implementations that have no thread support at all (they don't even link against pthreads). Forcing such an implementation to provide thread safety for a handful of functions is unreasonable. >>>>> >>>>> George. >>>>> >>>>> >>>>> On Tue, Mar 3, 2015 at 5:30 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>>> >>>>> Thanks. Jim/Jeff/Aurelien? >>>>> >>>>>> On Mar 3, 2015, at 4:29 PM, Daniel Holmes <dholmes(a)epcc.ed.ac.uk> wrote: >>>>>> >>>>>> I agree that this sentence should not be in the standard. >>>>>> >>>>>> Cheers, >>>>>> Dan. >>>>>> >>>>>> On 03/03/2015 14:24, Balaji, Pavan wrote: >>>>>>> The Forum was not entirely happy with the chapter committee change on the EI chapter. Specifically, the following sentence that was added into the pdf should be removed: >>>>>>> >>>>>>> "Implementations that do not support threads are not required to support the calling of these functions from threads." >>>>>>> >>>>>>> This is in direct contradiction to the fact that the mentioned functions should work correctly without knowing whether threads are there or not. I plan to remove it. Please let me know what you think. >>>>>>> >>>>>>> -- Pavan >>>>>>> >>>>>>> -- >>>>>>> Pavan Balaji ✉️ >>>>>>> http://www.mcs.anl.gov/~balaji >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mpiwg-hybridpm mailing list >>>>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>>>> >>>>>> -- >>>>>> Dan Holmes >>>>>> Applications Consultant in HPC Research >>>>>> EPCC, The University of Edinburgh >>>>>> James Clerk Maxwell Building >>>>>> The Kings Buildings >>>>>> Peter Guthrie Tait Road >>>>>> Edinburgh >>>>>> EH9 3FD >>>>>> T: +44(0)131 651 3465 >>>>>> E: dholmes(a)epcc.ed.ac.uk >>>>>> >>>>>> *Please consider the environment before printing this email.* >>>>>> >>>>>> >>>>>> The University of Edinburgh is a charitable body, registered in >>>>>> Scotland, with registration number SC005336. >>>>>> >>>>>> _______________________________________________ >>>>>> mpiwg-hybridpm mailing list >>>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>>> >>>>> -- >>>>> Pavan Balaji ✉️ >>>>> http://www.mcs.anl.gov/~balaji >>>>> >>>>> _______________________________________________ >>>>> mpiwg-hybridpm mailing list >>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>>> >>>>> _______________________________________________ >>>>> mpiwg-hybridpm mailing list >>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>> >>>> -- >>>> Pavan Balaji ✉️ >>>> http://www.mcs.anl.gov/~balaji >>>> >>>> _______________________________________________ >>>> mpiwg-hybridpm mailing list >>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>> >>> >>> >>> -- >>> Jeff Hammond >>> jeff.science(a)gmail.com >>> http://jeffhammond.github.io/ >>> _______________________________________________ >>> mpiwg-hybridpm mailing list >>> mpiwg-hybridpm(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >> >> -- >> Pavan Balaji ✉️ >> http://www.mcs.anl.gov/~balaji >> >> _______________________________________________ >> mpiwg-hybridpm mailing list >> mpiwg-hybridpm(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > mpiwg-hybridpm mailing list > mpiwg-hybridpm(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpiwg-hybridpm] Changes to the EI chapter
by Jeff Squyres (jsquyres) 03 Mar '15

03 Mar '15

On Mar 3, 2015, at 2:56 PM, George Bosilca <bosilca(a)icl.utk.edu> wrote: > > This change is a direct effect of the #357 ticket (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/357) that has been discussed and had received a successful vote (18 yes, 0 no, 1 abstain). > > Removing this particular part of the paragraph does not clarify all conflicts of this section. Few lines above there is an even bolder statement claiming that "Therefore, \MPI/ implementations are not required to be thread compliant as defined in this section." So to thread or not to thread? > > My understanding is that "implementation that do not support threads" are not referring to implementations that solely provide support for MPI_THREAD_SERIALIZED, Where is that defined? This is a question that came out of the forum: "What exactly does it mean to 'not support threads'? Every process has at least one thread." > but to implementations that have no thread support at all (they don't even link against pthreads). Not linking against pthreads doesn't mean anything -- every process still has at least 1 thread. > Forcing such an implementation to provide thread safety for a handful of functions is unreasonable. That was the whole point of the ticket: these functions are *always* thread safe. ...which is what Jeff Hammond wanted. :-) -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpiwg-hybridpm] Changes to the EI chapter
by Balaji, Pavan 03 Mar '15

03 Mar '15

It makes the Forum uncomfortable. I'm happy to bring it forward, but it'll likely get voted down. Your call. -- Pavan > On Mar 3, 2015, at 5:40 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > I wrote the primary wording. Ball is in your court to propose an > alternative if you don't like my version. But it has to preserve the > intent of the original text, not just remove it because it makes you > uncomfortable. > > Jeff > > On Tue, Mar 3, 2015 at 3:38 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >> Please suggest alternate wording. >> >> -- Pavan >> >>> On Mar 3, 2015, at 5:32 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >>> >>> I could be wrong, but if I wrote that sentence, I meant what George >>> said and not anything else. >>> >>> Jeff >>> >>> On Tue, Mar 3, 2015 at 3:24 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>> >>>> This was not what was voted on. The vote was based on the PDF, which doesn't contain this text. So the change is incorrect and comes under the chapter committee prerogative. >>>> >>>> Coming to the change itself, for environments that don't even allow multiple threads to exist, this is trivial for MPI implementations to provide. The concern is that before MPI_INIT_THREAD, I do not know if I can use THREAD_MULTIPLE or not. The user does not know and should be able to call these functions either way. >>>> >>>> -- Pavan >>>> >>>>> On Mar 3, 2015, at 4:56 PM, George Bosilca <bosilca(a)icl.utk.edu> wrote: >>>>> >>>>> This change is a direct effect of the #357 ticket (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/357) that has been discussed and had received a successful vote (18 yes, 0 no, 1 abstain). >>>>> >>>>> Removing this particular part of the paragraph does not clarify all conflicts of this section. Few lines above there is an even bolder statement claiming that "Therefore, \MPI/ implementations are not required to be thread compliant as defined in this section." So to thread or not to thread? >>>>> >>>>> My understanding is that "implementation that do not support threads" are not referring to implementations that solely provide support for MPI_THREAD_SERIALIZED, but to implementations that have no thread support at all (they don't even link against pthreads). Forcing such an implementation to provide thread safety for a handful of functions is unreasonable. >>>>> >>>>> George. >>>>> >>>>> >>>>> On Tue, Mar 3, 2015 at 5:30 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >>>>> >>>>> Thanks. Jim/Jeff/Aurelien? >>>>> >>>>>> On Mar 3, 2015, at 4:29 PM, Daniel Holmes <dholmes(a)epcc.ed.ac.uk> wrote: >>>>>> >>>>>> I agree that this sentence should not be in the standard. >>>>>> >>>>>> Cheers, >>>>>> Dan. >>>>>> >>>>>> On 03/03/2015 14:24, Balaji, Pavan wrote: >>>>>>> The Forum was not entirely happy with the chapter committee change on the EI chapter. Specifically, the following sentence that was added into the pdf should be removed: >>>>>>> >>>>>>> "Implementations that do not support threads are not required to support the calling of these functions from threads." >>>>>>> >>>>>>> This is in direct contradiction to the fact that the mentioned functions should work correctly without knowing whether threads are there or not. I plan to remove it. Please let me know what you think. >>>>>>> >>>>>>> -- Pavan >>>>>>> >>>>>>> -- >>>>>>> Pavan Balaji ✉️ >>>>>>> http://www.mcs.anl.gov/~balaji >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mpiwg-hybridpm mailing list >>>>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>>>> >>>>>> -- >>>>>> Dan Holmes >>>>>> Applications Consultant in HPC Research >>>>>> EPCC, The University of Edinburgh >>>>>> James Clerk Maxwell Building >>>>>> The Kings Buildings >>>>>> Peter Guthrie Tait Road >>>>>> Edinburgh >>>>>> EH9 3FD >>>>>> T: +44(0)131 651 3465 >>>>>> E: dholmes(a)epcc.ed.ac.uk >>>>>> >>>>>> *Please consider the environment before printing this email.* >>>>>> >>>>>> >>>>>> The University of Edinburgh is a charitable body, registered in >>>>>> Scotland, with registration number SC005336. >>>>>> >>>>>> _______________________________________________ >>>>>> mpiwg-hybridpm mailing list >>>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>>> >>>>> -- >>>>> Pavan Balaji ✉️ >>>>> http://www.mcs.anl.gov/~balaji >>>>> >>>>> _______________________________________________ >>>>> mpiwg-hybridpm mailing list >>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>>> >>>>> _______________________________________________ >>>>> mpiwg-hybridpm mailing list >>>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>>> >>>> -- >>>> Pavan Balaji ✉️ >>>> http://www.mcs.anl.gov/~balaji >>>> >>>> _______________________________________________ >>>> mpiwg-hybridpm mailing list >>>> mpiwg-hybridpm(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>> >>> >>> >>> -- >>> Jeff Hammond >>> jeff.science(a)gmail.com >>> http://jeffhammond.github.io/ >>> _______________________________________________ >>> mpiwg-hybridpm mailing list >>> mpiwg-hybridpm(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >> >> -- >> Pavan Balaji ✉️ >> http://www.mcs.anl.gov/~balaji >> >> _______________________________________________ >> mpiwg-hybridpm mailing list >> mpiwg-hybridpm(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > mpiwg-hybridpm mailing list > mpiwg-hybridpm(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

1 0