February 2012 - mpiwg-io - mailman3.cels.anl.gov

Re: [MPI3-IO] shared file pointer
by Quincey Koziol 13 Feb '12

13 Feb '12

Hi Mohamad, On Feb 12, 2012, at 11:52 AM, Mohamad Chaarawi wrote: > Hi All, > > So after laying out these choices, I see 3 options for the nbcio ticket: > > 1) Keep it the way it is, and adding an advise to users saying that intermixing nonblocking collective shared fp operation and independent shared fp operations is undefined. > > 2) Make the previous case illegal. > > 3) remove the nonblocking ordered operations from this ticket (to be handled in a separate ticket) > > keep in mind, as mentioned previously, we can't provide a prototype implementation for those routines. From our side, if the forum accepts only a pseudo code implementation for those routines, we would like to proceed with option 1, otherwise we would go with option 3. Sounds good to me. Quincey > > Any other opinions? > > Thanks, > Mohamad > > On 2/6/2012 1:19 PM, Dries Kimpe wrote: >> >> Yes, that's an accurate summary. >> >> Dries >> >> * Mohamad Chaarawi <chaarawi(a)hdfgroup.org> [2012-02-06 10:48:50]: >> >>> Hi Dries, >>> I'm jumping late on this thread, but to summarize so far (and correct me >>> if I made a mistake understanding), we have two cases: >>> 1) two non-blocking collective shared FP operations: >>> MPI_File_iread_ordered >>> MPI_File_iread_ordered >>> This will be ordered in the sense that the user will see that the first >>> operations will occur before the second one. >>> 2) mixed collective and independent >>> MPI_File_iread_ordered >>> MPI_File_read_shared >>> Where the choices that you mentioned apply, right? >>> * make that case illegal >>> * make it undefined >>> As you mentioned that since the split collectives leave it as undefined, >>> makes me lean more towards keeping it that way. >>> Thanks, >>> Mohamad >> >> >>> On 02/02/2012 04:22 PM, Dries Kimpe wrote: >>>> There might be some use in 'undefined ordering' as opposed to 'illegal' >>>> for those application that don't care about the ordering. >>>> Applications that do rely on the ordering can easily use the existing MPI >>>> functions to enforce ordering. >>>> So, the way I see it: 2 choices: >>>> 1) Say order is undefined in the standard (basically there's a precedent >>>> with the split collective versions). >>>> 2) Say it is illegal. The user can duplicate the file handle and easily >>>> implement their own version of what they need. >>>> (2) is easier for the implementor. >> >> >>> _______________________________________________ >>> MPI3-IO mailing list >>> MPI3-IO(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io >> >> >> _______________________________________________ >> MPI3-IO mailing list >> MPI3-IO(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io > > _______________________________________________ > MPI3-IO mailing list > MPI3-IO(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io

1 0

Re: [MPI3-IO] shared file pointer
by Mohamad Chaarawi 12 Feb '12

12 Feb '12

Hi All, So after laying out these choices, I see 3 options for the nbcio ticket: 1) Keep it the way it is, and adding an advise to users saying that intermixing nonblocking collective shared fp operation and independent shared fp operations is undefined. 2) Make the previous case illegal. 3) remove the nonblocking ordered operations from this ticket (to be handled in a separate ticket) keep in mind, as mentioned previously, we can't provide a prototype implementation for those routines. From our side, if the forum accepts only a pseudo code implementation for those routines, we would like to proceed with option 1, otherwise we would go with option 3. Any other opinions? Thanks, Mohamad On 2/6/2012 1:19 PM, Dries Kimpe wrote: > Yes, that's an accurate summary. > > Dries > > * Mohamad Chaarawi<chaarawi(a)hdfgroup.org> [2012-02-06 10:48:50]: > >> Hi Dries, >> I'm jumping late on this thread, but to summarize so far (and correct me >> if I made a mistake understanding), we have two cases: >> 1) two non-blocking collective shared FP operations: >> MPI_File_iread_ordered >> MPI_File_iread_ordered >> This will be ordered in the sense that the user will see that the first >> operations will occur before the second one. >> 2) mixed collective and independent >> MPI_File_iread_ordered >> MPI_File_read_shared >> Where the choices that you mentioned apply, right? >> * make that case illegal >> * make it undefined >> As you mentioned that since the split collectives leave it as undefined, >> makes me lean more towards keeping it that way. >> Thanks, >> Mohamad > > >> On 02/02/2012 04:22 PM, Dries Kimpe wrote: >>> There might be some use in 'undefined ordering' as opposed to 'illegal' >>> for those application that don't care about the ordering. >>> Applications that do rely on the ordering can easily use the existing MPI >>> functions to enforce ordering. >>> So, the way I see it: 2 choices: >>> 1) Say order is undefined in the standard (basically there's a precedent >>> with the split collective versions). >>> 2) Say it is illegal. The user can duplicate the file handle and easily >>> implement their own version of what they need. >>> (2) is easier for the implementor. > > >> _______________________________________________ >> MPI3-IO mailing list >> MPI3-IO(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io > > > _______________________________________________ > MPI3-IO mailing list > MPI3-IO(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io

1 0

Re: [MPI3-IO] Fault Tolerance & I/O Discussion
by Josh Hursey 08 Feb '12

08 Feb '12

We will meet Wednesday, Feb. 15 at 11 am Eastern to continue our discussion of fault tolerance in the I/O chapter. We can use the following teleconf information: US Toll Free number: 877-801-8130 Toll number: 1-203-692-8690 Access Code: 1044056 Thanks, Josh On Mon, Feb 6, 2012 at 2:40 PM, Josh Hursey <jjhursey(a)open-mpi.org> wrote: > We had a good discussion today. Attached are some notes that I took from > the call. > > There were a few questions that we were discussing at the end of the call. > As a result we are going to try to setup another teleconf. > > Below is a doodle poll to pick a date/time: > http://www.doodle.com/zw83eht6hh8mwmic > > If you are interested in attending this teleconf, please fill out the poll > by 2 pm Eastern on Wednesday, Feb. 8. > > In the mean time let us keep discussing these issues on the FT and I/O > mailing lists. My preference would be to just discuss it on the FT mailing > list as there are more FT folks over there, and then we would not distract > the discussions about the other I/O tickets. > > Thanks, > Josh > > On Mon, Feb 6, 2012 at 10:55 AM, Josh Hursey <jjhursey(a)open-mpi.org>wrote: > >> Just a reminder that we are meeting today at Noon Eastern. Enclosed are >> the call-in details and a link to the FT stabilization proposal. >> >> Thanks, >> Josh >> >> >> On Thu, Feb 2, 2012 at 2:46 PM, Josh Hursey <jjhursey(a)open-mpi.org>wrote: >> >>> We will meet Monday, Feb. 6 from 12-1 pm EST/New York to discuss I/O in >>> the context of the fault tolerance proposal (or the Super Bowl if we get >>> bored). >>> >>> We can use the following teleconf information: >>> US Toll Free number: 877-801-8130 >>> Toll number: 1-203-692-8690 >>> Access Code: 1044056 >>> >>> The Run-Through Stabilization proposal can be found attached to the >>> ticket: >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/276 >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/276/FTWG-Pro… >>> >>> We will be primarily focusing on section 17.12 of that document. I will >>> try to send out a reminder the day of. >>> >>> Thanks, >>> Josh >>> >>> On Tue, Jan 31, 2012 at 5:04 PM, Josh Hursey <jjhursey(a)open-mpi.org>wrote: >>> >>>> Try the new link (I had to close the other poll due to a timezone >>>> problem): >>>> http://www.doodle.com/yifhpi5emyyzrspa >>>> >>>> -- Josh >>>> >>>> >>>> On Tue, Jan 31, 2012 at 4:41 PM, Mohamad Chaarawi < >>>> chaarawi(a)hdfgroup.org> wrote: >>>> >>>>> Hi Josh, >>>>> >>>>> When I click the link, it says the poll has been deleted. >>>>> >>>>> Thanks, >>>>> Mohamad >>>>> >>>>> >>>>> On 01/31/2012 11:52 AM, Josh Hursey wrote: >>>>> >>>>> (Cross posted to both the I/O and FT MPI-3 listservs) >>>>> >>>>> During the FT plenary session at the Jan. MPI Forum meeting there >>>>> were some concerns about fault tolerance semantics in the I/O chapter. We >>>>> did not have much time to fully discuss the additional semantics during the >>>>> meeting. To make sure that we push towards a complete set of semantics >>>>> useful for the I/O community in the next draft I would like to have a >>>>> teleconf to discuss the I/O chapter of the FT proposal. Preferability in >>>>> the next week and a half (so we have time to fine tune things before the >>>>> next forum meeting). >>>>> >>>>> Below is a link to a doodle poll to find a good time for a teleconf. >>>>> If you are interested in participating in this discussion, please fill this >>>>> poll out by 2 PM Eastern on Thurs. Feb. 2 so we can set the date/time. >>>>> http://www.doodle.com/s3hz9daeh8pn483m >>>>> >>>>> Thanks, >>>>> Josh >>>>> >>>>> -- >>>>> Joshua Hursey >>>>> Postdoctoral Research Associate >>>>> Oak Ridge National Laboratory >>>>> http://users.nccs.gov/~jjhursey >>>>> >>>>> >>>>> _______________________________________________ >>>>> MPI3-IO mailing [email protected]://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> MPI3-IO mailing list >>>>> MPI3-IO(a)lists.mpi-forum.org >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io >>>>> >>>>> >>>> >>>> >>>> -- >>>> Joshua Hursey >>>> Postdoctoral Research Associate >>>> Oak Ridge National Laboratory >>>> http://users.nccs.gov/~jjhursey >>>> >>> >>> >>> >>> -- >>> Joshua Hursey >>> Postdoctoral Research Associate >>> Oak Ridge National Laboratory >>> http://users.nccs.gov/~jjhursey >>> >> >> >> >> -- >> Joshua Hursey >> Postdoctoral Research Associate >> Oak Ridge National Laboratory >> http://users.nccs.gov/~jjhursey >> > > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

Re: [MPI3-IO] Fault Tolerance & I/O Discussion
by Josh Hursey 06 Feb '12

06 Feb '12

We had a good discussion today. Attached are some notes that I took from the call. There were a few questions that we were discussing at the end of the call. As a result we are going to try to setup another teleconf. Below is a doodle poll to pick a date/time: http://www.doodle.com/zw83eht6hh8mwmic If you are interested in attending this teleconf, please fill out the poll by 2 pm Eastern on Wednesday, Feb. 8. In the mean time let us keep discussing these issues on the FT and I/O mailing lists. My preference would be to just discuss it on the FT mailing list as there are more FT folks over there, and then we would not distract the discussions about the other I/O tickets. Thanks, Josh On Mon, Feb 6, 2012 at 10:55 AM, Josh Hursey <jjhursey(a)open-mpi.org> wrote: > Just a reminder that we are meeting today at Noon Eastern. Enclosed are > the call-in details and a link to the FT stabilization proposal. > > Thanks, > Josh > > > On Thu, Feb 2, 2012 at 2:46 PM, Josh Hursey <jjhursey(a)open-mpi.org> wrote: > >> We will meet Monday, Feb. 6 from 12-1 pm EST/New York to discuss I/O in >> the context of the fault tolerance proposal (or the Super Bowl if we get >> bored). >> >> We can use the following teleconf information: >> US Toll Free number: 877-801-8130 >> Toll number: 1-203-692-8690 >> Access Code: 1044056 >> >> The Run-Through Stabilization proposal can be found attached to the >> ticket: >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/276 >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/276/FTWG-Pro… >> >> We will be primarily focusing on section 17.12 of that document. I will >> try to send out a reminder the day of. >> >> Thanks, >> Josh >> >> On Tue, Jan 31, 2012 at 5:04 PM, Josh Hursey <jjhursey(a)open-mpi.org>wrote: >> >>> Try the new link (I had to close the other poll due to a timezone >>> problem): >>> http://www.doodle.com/yifhpi5emyyzrspa >>> >>> -- Josh >>> >>> >>> On Tue, Jan 31, 2012 at 4:41 PM, Mohamad Chaarawi <chaarawi(a)hdfgroup.org >>> > wrote: >>> >>>> Hi Josh, >>>> >>>> When I click the link, it says the poll has been deleted. >>>> >>>> Thanks, >>>> Mohamad >>>> >>>> >>>> On 01/31/2012 11:52 AM, Josh Hursey wrote: >>>> >>>> (Cross posted to both the I/O and FT MPI-3 listservs) >>>> >>>> During the FT plenary session at the Jan. MPI Forum meeting there >>>> were some concerns about fault tolerance semantics in the I/O chapter. We >>>> did not have much time to fully discuss the additional semantics during the >>>> meeting. To make sure that we push towards a complete set of semantics >>>> useful for the I/O community in the next draft I would like to have a >>>> teleconf to discuss the I/O chapter of the FT proposal. Preferability in >>>> the next week and a half (so we have time to fine tune things before the >>>> next forum meeting). >>>> >>>> Below is a link to a doodle poll to find a good time for a teleconf. >>>> If you are interested in participating in this discussion, please fill this >>>> poll out by 2 PM Eastern on Thurs. Feb. 2 so we can set the date/time. >>>> http://www.doodle.com/s3hz9daeh8pn483m >>>> >>>> Thanks, >>>> Josh >>>> >>>> -- >>>> Joshua Hursey >>>> Postdoctoral Research Associate >>>> Oak Ridge National Laboratory >>>> http://users.nccs.gov/~jjhursey >>>> >>>> >>>> _______________________________________________ >>>> MPI3-IO mailing [email protected]://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io >>>> >>>> >>>> >>>> _______________________________________________ >>>> MPI3-IO mailing list >>>> MPI3-IO(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io >>>> >>>> >>> >>> >>> -- >>> Joshua Hursey >>> Postdoctoral Research Associate >>> Oak Ridge National Laboratory >>> http://users.nccs.gov/~jjhursey >>> >> >> >> >> -- >> Joshua Hursey >> Postdoctoral Research Associate >> Oak Ridge National Laboratory >> http://users.nccs.gov/~jjhursey >> > > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

Re: [MPI3-IO] shared file pointer
by Dries Kimpe 06 Feb '12

06 Feb '12

Yes, that's an accurate summary. Dries * Mohamad Chaarawi <chaarawi(a)hdfgroup.org> [2012-02-06 10:48:50]: > Hi Dries, > I'm jumping late on this thread, but to summarize so far (and correct me > if I made a mistake understanding), we have two cases: > 1) two non-blocking collective shared FP operations: > MPI_File_iread_ordered > MPI_File_iread_ordered > This will be ordered in the sense that the user will see that the first > operations will occur before the second one. > 2) mixed collective and independent > MPI_File_iread_ordered > MPI_File_read_shared > Where the choices that you mentioned apply, right? > * make that case illegal > * make it undefined > As you mentioned that since the split collectives leave it as undefined, > makes me lean more towards keeping it that way. > Thanks, > Mohamad > On 02/02/2012 04:22 PM, Dries Kimpe wrote: > > There might be some use in 'undefined ordering' as opposed to 'illegal' > > for those application that don't care about the ordering. > > Applications that do rely on the ordering can easily use the existing MPI > > functions to enforce ordering. > > So, the way I see it: 2 choices: > > 1) Say order is undefined in the standard (basically there's a precedent > > with the split collective versions). > > 2) Say it is illegal. The user can duplicate the file handle and easily > > implement their own version of what they need. > > (2) is easier for the implementor. > _______________________________________________ > MPI3-IO mailing list > MPI3-IO(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io

1 0

Re: [MPI3-IO] shared file pointer
by Mohamad Chaarawi 06 Feb '12

06 Feb '12

Hi Dries, I'm jumping late on this thread, but to summarize so far (and correct me if I made a mistake understanding), we have two cases: 1) two non-blocking collective shared FP operations: MPI_File_iread_ordered MPI_File_iread_ordered This will be ordered in the sense that the user will see that the first operations will occur before the second one. 2) mixed collective and independent MPI_File_iread_ordered MPI_File_read_shared Where the choices that you mentioned apply, right? * make that case illegal * make it undefined As you mentioned that since the split collectives leave it as undefined, makes me lean more towards keeping it that way. Thanks, Mohamad On 02/02/2012 04:22 PM, Dries Kimpe wrote: > There might be some use in 'undefined ordering' as opposed to 'illegal' > for those application that don't care about the ordering. > > Applications that do rely on the ordering can easily use the existing MPI > functions to enforce ordering. > > So, the way I see it: 2 choices: > 1) Say order is undefined in the standard (basically there's a precedent > with the split collective versions). > 2) Say it is illegal. The user can duplicate the file handle and easily > implement their own version of what they need. > > (2) is easier for the implementor.

1 0

Re: [MPI3-IO] Fault Tolerance & I/O Discussion
by Josh Hursey 06 Feb '12

06 Feb '12

Just a reminder that we are meeting today at Noon Eastern. Enclosed are the call-in details and a link to the FT stabilization proposal. Thanks, Josh On Thu, Feb 2, 2012 at 2:46 PM, Josh Hursey <jjhursey(a)open-mpi.org> wrote: > We will meet Monday, Feb. 6 from 12-1 pm EST/New York to discuss I/O in > the context of the fault tolerance proposal (or the Super Bowl if we get > bored). > > We can use the following teleconf information: > US Toll Free number: 877-801-8130 > Toll number: 1-203-692-8690 > Access Code: 1044056 > > The Run-Through Stabilization proposal can be found attached to the ticket: > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/276 > > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/276/FTWG-Pro… > > We will be primarily focusing on section 17.12 of that document. I will > try to send out a reminder the day of. > > Thanks, > Josh > > On Tue, Jan 31, 2012 at 5:04 PM, Josh Hursey <jjhursey(a)open-mpi.org>wrote: > >> Try the new link (I had to close the other poll due to a timezone >> problem): >> http://www.doodle.com/yifhpi5emyyzrspa >> >> -- Josh >> >> >> On Tue, Jan 31, 2012 at 4:41 PM, Mohamad Chaarawi <chaarawi(a)hdfgroup.org>wrote: >> >>> Hi Josh, >>> >>> When I click the link, it says the poll has been deleted. >>> >>> Thanks, >>> Mohamad >>> >>> >>> On 01/31/2012 11:52 AM, Josh Hursey wrote: >>> >>> (Cross posted to both the I/O and FT MPI-3 listservs) >>> >>> During the FT plenary session at the Jan. MPI Forum meeting there were >>> some concerns about fault tolerance semantics in the I/O chapter. We did >>> not have much time to fully discuss the additional semantics during the >>> meeting. To make sure that we push towards a complete set of semantics >>> useful for the I/O community in the next draft I would like to have a >>> teleconf to discuss the I/O chapter of the FT proposal. Preferability in >>> the next week and a half (so we have time to fine tune things before the >>> next forum meeting). >>> >>> Below is a link to a doodle poll to find a good time for a teleconf. >>> If you are interested in participating in this discussion, please fill this >>> poll out by 2 PM Eastern on Thurs. Feb. 2 so we can set the date/time. >>> http://www.doodle.com/s3hz9daeh8pn483m >>> >>> Thanks, >>> Josh >>> >>> -- >>> Joshua Hursey >>> Postdoctoral Research Associate >>> Oak Ridge National Laboratory >>> http://users.nccs.gov/~jjhursey >>> >>> >>> _______________________________________________ >>> MPI3-IO mailing [email protected]://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io >>> >>> >>> >>> _______________________________________________ >>> MPI3-IO mailing list >>> MPI3-IO(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io >>> >>> >> >> >> -- >> Joshua Hursey >> Postdoctoral Research Associate >> Oak Ridge National Laboratory >> http://users.nccs.gov/~jjhursey >> > > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

Re: [MPI3-IO] shared file pointer
by Dries Kimpe 02 Feb '12

02 Feb '12

* Quincey Koziol <koziol(a)hdfgroup.org> [2012-02-01 17:31:39]: [...] > > I guess the same technique (and attribute) could be used for the > > independent shared fp operations, but I'm really no fan of that. > > If only because when we do that, the independent shared fp update really > > becomes collective, as it will block until some other MPI rank completes > > the collective shared fp update. > > I would prefer to leave that as undefined ordering, because to me it > > really feels like doing two non-blocking receives using the same target > > buffer. > I'm neutral on it from a user (i.e. HDF5) perspective, since I > don't think anyone will actually use the feature. But, if someone > did, would an undefined ordering be an OK thing for them too? If > so, we can say that the order is undefined in the standard and > leave it at that... There might be some use in 'undefined ordering' as opposed to 'illegal' for those application that don't care about the ordering. Applications that do rely on the ordering can easily use the existing MPI functions to enforce ordering. So, the way I see it: 2 choices: 1) Say order is undefined in the standard (basically there's a precedent with the split collective versions). 2) Say it is illegal. The user can duplicate the file handle and easily implement their own version of what they need. (2) is easier for the implementor. Dries

1 0

Re: [MPI3-IO] Fault Tolerance & I/O Discussion
by Josh Hursey 02 Feb '12

02 Feb '12

We will meet Monday, Feb. 6 from 12-1 pm EST/New York to discuss I/O in the context of the fault tolerance proposal (or the Super Bowl if we get bored). We can use the following teleconf information: US Toll Free number: 877-801-8130 Toll number: 1-203-692-8690 Access Code: 1044056 The Run-Through Stabilization proposal can be found attached to the ticket: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/276 https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/276/FTWG-Pro… We will be primarily focusing on section 17.12 of that document. I will try to send out a reminder the day of. Thanks, Josh On Tue, Jan 31, 2012 at 5:04 PM, Josh Hursey <jjhursey(a)open-mpi.org> wrote: > Try the new link (I had to close the other poll due to a timezone problem): > http://www.doodle.com/yifhpi5emyyzrspa > > -- Josh > > > On Tue, Jan 31, 2012 at 4:41 PM, Mohamad Chaarawi <chaarawi(a)hdfgroup.org>wrote: > >> Hi Josh, >> >> When I click the link, it says the poll has been deleted. >> >> Thanks, >> Mohamad >> >> >> On 01/31/2012 11:52 AM, Josh Hursey wrote: >> >> (Cross posted to both the I/O and FT MPI-3 listservs) >> >> During the FT plenary session at the Jan. MPI Forum meeting there were >> some concerns about fault tolerance semantics in the I/O chapter. We did >> not have much time to fully discuss the additional semantics during the >> meeting. To make sure that we push towards a complete set of semantics >> useful for the I/O community in the next draft I would like to have a >> teleconf to discuss the I/O chapter of the FT proposal. Preferability in >> the next week and a half (so we have time to fine tune things before the >> next forum meeting). >> >> Below is a link to a doodle poll to find a good time for a teleconf. If >> you are interested in participating in this discussion, please fill this >> poll out by 2 PM Eastern on Thurs. Feb. 2 so we can set the date/time. >> http://www.doodle.com/s3hz9daeh8pn483m >> >> Thanks, >> Josh >> >> -- >> Joshua Hursey >> Postdoctoral Research Associate >> Oak Ridge National Laboratory >> http://users.nccs.gov/~jjhursey >> >> >> _______________________________________________ >> MPI3-IO mailing [email protected]://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io >> >> >> >> _______________________________________________ >> MPI3-IO mailing list >> MPI3-IO(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-io >> >> > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

Re: [MPI3-IO] shared file pointer
by Quincey Koziol 01 Feb '12

01 Feb '12

Hi Dries, On Feb 1, 2012, at 3:37 PM, Dries Kimpe wrote: > > > * Torsten Hoefler <htor(a)illinois.edu> [2012-02-01 15:18:41]: > >>> Because of the MPI_Iscan properties, a second MPI_File_iread_ordered could >>> not proceed before the first one finished the scan phase, hence they would >>> be properly ordered. >> Well, they *can* complete out of order (not match though!) you need to >> make sure the order it preserved. > > Good point. > > For this to work, we need an atomic Iscan + update fp. > In other words, we also have to order FP update operations. > But that is pretty easy to do, by using an attribute on the file handle. > > MPI_File_iread_ordered: > lock > -> get sequence number from file handle attribute, store number > with operation > -> add our number at the end of a list in attribute on file handle > unlock > > start and wait (non-blocking) for iscan > > if iscan completes: wait until the number at the front of the list > (in attribute is ours). > if it is: > update shared fp and remove from list > else > wait. > > do ifile_read_at. > > > Obviously, there are better ways of doing this. The main point is that we > need to introduce an extra dependency on the update for the shared fp so > that we wait until any earlier operation already updated the shared fp. > > I guess the same technique (and attribute) could be used for the > independent shared fp operations, but I'm really no fan of that. > > If only because when we do that, the independent shared fp update really > becomes collective, as it will block until some other MPI rank completes > the collective shared fp update. > > I would prefer to leave that as undefined ordering, because to me it > really feels like doing two non-blocking receives using the same target > buffer. I'm neutral on it from a user (i.e. HDF5) perspective, since I don't think anyone will actually use the feature. But, if someone did, would an undefined ordering be an OK thing for them too? If so, we can say that the order is undefined in the standard and leave it at that... Quincey

1 0