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

[Barrett, Brian W]

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.  The problems with file position and ordering is still a bit unsettling to some.

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.

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