[Mpi-forum] [EXTERNAL] Re: ticket 273

Mohamad Chaarawi chaarawi at hdfgroup.org
Wed May 30 18:37:06 CDT 2012


Hi Brian,

On 5/30/2012 5:22 PM, Barrett, Brian W wrote:
> Mohamad -
>
> I can't speak for others.  I can say that there was a general feeling from those who voted no or abstain that the need for a non-blocking file I/O collective, when split collectives are already unable to provide any asynchrony, is a problem for implementors.

I agree with you that an implementation is not easy for those routines.. 
But I don't see that it should be a reason for voting a ticket down, or 
worse saying that it should be postponed, because the implementation 
challenge will still be there for 3.1

> The problems with file position and ordering is still a bit unsettling to some.

Is that something new for any of the file routines (blocking and non 
blocking)? The consistency semantics are defined as clear as any of the 
other file routines.

>
> Also, I know that for myself, I haven't voiced objections in the last couple of meetings because my objections had been made previously and not well addressed, so I was going to vote no.  This happens in any voting body.
>
> It was poor scheduling that the last first vote occurred on a foreign trip.  I tried very hard to get someone to speak up about each ticket ahead of time, as I can't speak for many of the tickets (and it would not be fair for me to give initial background on a ticket I was going to vote "no" for).  This was obviously problematic for some tickets.  The discussion on the ifile ticket largely covered the points I raised in the initial paragraph.

Admittedly I might have done something to try and get people to speak up 
about this ticket a couple of weeks before the meeting, but my problem 
with this, by looking at my slides for all the presentations I made for 
this ticket where I record all the straw votes, there were two straw 
votes at 2 separate meetings, a 17-0-1 and another similar straw votes 
on this ticket. The ticket that got a lot of objections (many from you) 
was the nonblocking file manipulation routines ticket, which was withdrawn.
The only problem that was voiced for this ticket was the issue with 
shared file pointers. This was addressed at the last meeting, and 
everybody seemed content with the draft read.

I don't want to sound stubborn here, but  between the voting rules 
change, and the lack of feedback given from people for this ticket, I'm 
a bit frustrated.

Mohamad

>
> Unlike some of the other tickets that were voted down, the ifile ticket was one of two (FT being the other) that people were more receptive to seeing in MPI-3.1.
>
> Brian
>
> --
>    Brian W. Barrett
>    Scalable System Software Group
>    Sandia National Laboratories
> ________________________________________
> From: mpi-forum-bounces at lists.mpi-forum.org [mpi-forum-bounces at lists.mpi-forum.org] on behalf of Mohamad Chaarawi [chaarawi at hdfgroup.org]
> Sent: Wednesday, May 30, 2012 2:24 PM
> To: mpi-forum at lists.mpi-forum.org
> Subject: [EXTERNAL] Re: [Mpi-forum] ticket 273
>
> Hi Rich,
>
> On 5/30/2012 3:03 PM, Richard Graham wrote:
>> Mohamad,
>>     Two items that I wrote down based on comments:
>>    - One view was expressed that adding a nonblocking interface, will not change the fact that implementation will still be blocking
> The implementation that UH provides builds on top of libnbc which
> implements the non-blocking collective communication operations.. They
> use non blocking point-to-point operations and asynchronous
> aio_read/aio_write functions. So what part of that is blocking?
>
> btw, why was this concern not mentioned during the formal reading or on
> the I/O mailing list?
>
>> - The ticket was rushed, and not ready
> This ticket was going back and forth for a little less than a year.. I
> don't any reason why it is considered rushed.. Again most of the I/O
> chapter committee reviewed and approved it..
> Other than final merging issues what was wrong with ticket? and again
> why were they not brought up till the Japan vote, where we were not
> there to address them?
>
> Thanks,
> Mohamad
>
>> Rich
>>
>> -----Original Message-----
>> From: mpi-forum-bounces at lists.mpi-forum.org [mailto:mpi-forum-bounces at lists.mpi-forum.org] On Behalf Of Mohamad Chaarawi
>> Sent: Thursday, May 31, 2012 4:37 AM
>> To: Main MPI Forum mailing list
>> Subject: [Mpi-forum] ticket 273
>>
>> Hi All,
>>
>> I'm still trying to figure out why ticket 273 was voted down. At the last meeting, I would say there was a consensus that the non blocking collective I/O ticket (273) was ready to be voted in. Nobody expressed an objection after me removing the shared file pointer nbc routines and re-reading the draft. All the I/O chapter committee reviewed the draft and commented on the ticket that it looks good.
>>
>> At the Japan meeting, we get 8 yes , 2 nos, and 6 abstains, which under the new rules marks the ticket as failed.
>> None from our organization could attend the meeting to really understand what the 2 no votes were for, and why 6 organizations abstained.
>> If the abstains are because people don't care or don't understand what is being voted on or missed the vote (which are the reasons why I vote abstain), then the new voting rule doesn't really make sense. If the abstains where for something else, then the votes should be NO. So could someone mention why this was voted down?
>>
>> Thanks,
>> Mohamad
>>
>> _______________________________________________
>> mpi-forum mailing list
>> mpi-forum at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>>
>> _______________________________________________
>> mpi-forum mailing list
>> mpi-forum at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>
>
>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum





More information about the mpi-forum mailing list