Message-Id: <374EBBEB.4BE57E0C@etnus.com>
Date: Fri, 28 May 1999 16:53:15 +0100
From: James Cownie <jcownie@etnus.com>
Organization: Etnus, Inc.
Mime-Version: 1.0
Newsgroups: comp.parallel.mpi
Subject: Re: problems with MPI_Cancel()
References: <374DB25B.C5963D17@sd.aetc.com>
    <7imcpv$8qo$1@walter-fddi.cray.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Xref: ukc comp.parallel.mpi:5145


Eric Salo wrote:
> 
> In general, it is not a good idea to try to use MPI_Cancel() on a send.
> Note that the MPI Standard in no way guarantees that the cancel will
> succeed, and it is in fact perfectly legal to implement it as follows:
> 
>         int
>         MPI_Cancel(...)
>         {
>                 if (request_is_a_send) {
>                         return failure;
>                 }
>         }
> 
> Which is exactly what some implementations do, and even those that claim
> to have a "proper" implementation are not to be trusted IMHO.
> 
> Basically, MPI is just a really lousy fit for what you are trying to do.

I think you need to read the standard again, Eric...

The standard says (page 79 of first edition of "MPI the complete
reference")

  Either the cancelation succeeds, and no communication occurs, or the 
  communication completes, and the cancelation fails.
  If a send is marked for cancelation, then it must be the case that
either
  the send completes normally, and the message sent is received at the 
  destination process, or that the send is successfully canceled, and no
  part of the receive buffer is altered.

  If a communication is marked for cancelation, then a completion call 
  for that communication is guaranteed to return, irrespective of the
  activities of other processes.

So, an implementation of MPI_Cancel like the one above does *not* meet
the requirements of the standard.

If MPI_Cancel returns the result that it cannot cancel the operation,
then
that necessarily implies that the operation must already have reached a
stage
where it is guaranteed to complete on its own.

I know you didn't like these semantics at the time, but that's what we 
voted in...

-- Jim 

James Cownie	<jcownie@etnus.com>
Etnus, Inc.     +44 117 9071438
http://www.etnus.com