Newsgroups: comp.parallel.mpi
From: Steve Barnard <steve@megafauna.com>
Reply-To: steve@megafauna.com
Subject: Re: MPI Non blocking Sends, send buffer not readable or unclear standard?
Organization: megafauna
Date: Tue, 28 May 1996 18:57:58 -0800
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <31ABBD36.3073@megafauna.com>

Graham Nash wrote:
> 
> Eric Salo wrote:
> >
> > The standard is correct as written, strictly speaking you are not allowed
> > to even read the contents of your own send buffer until the send operation
> > completes. For blocking sends, of course, this is not an issue. If you want
> > to send the same data to multiple processes at once, use MPI_Bcast().
> >
> > This restriction was put in to allow implementors more flexibility to use
> > (for example) special hardware with dubious cache-coherency properties. On
> > the other hand, I am personally unaware of any specific implementations for
> > which reading the send buffer early would cause erroneous behavior.
> >
> 
> I would have thought that DMA constraints would be as important as
> cache-coherency. It is often difficult to convince hardware to
> perform multiple DMA's out of the same buffer without introducing
> serious hold-ups in providing the data to the channel. If you have
> high-performance channels, this could well be the difference between
> sending out the data successfully, or it timing out. Of course, all
> this pre-supposes you have multiple channels and you are sending the
> data directly from user space. If you have to copy the buffer to
> the kernel, then the pb goes away.
> The only pb with re-using the buffer is that it might not work. The
> standard is certainly correct in imposing this constraint, but a
> programmer is always free to ignore the standard at the risk of losing
> portability. It's his (or her) decision.
> 
> Graham Nash

I can't agree with this.  Standards don't come out of the blue.  The 
whole point of something like MPI is give users something useful and 
something they can rely on.  If there is a gratuitous and annoying (and 
even crippling) restriction that no implementors have even felt the need 
to exploit, it should go.

 Steve Barnard

