From: salo@cray.com (Eric Salo)
Newsgroups: comp.parallel.mpi
Subject: Re: problems with MPI_Cancel()
Date: 2 Jun 1999 05:44:12 GMT
Organization: Silicon Graphics, Inc.
Message-Id: <7j2gbc$p8p$1@walter-fddi.cray.com>
References: <374DB25B.C5963D17@sd.aetc.com> <374EBBEB.4BE57E0C@etnus.com>
    <7ipl72$sn8$1@walter-fddi.cray.com> <3754021E.61DF3667@etnus.com>
Xref: ukc comp.parallel.mpi:5157


> In your second post you seem to accept that this is *NOT* a valid 
> implementation, which was my point exactly. What the standard says
> is clear. What implementations do is a different kettle of fish.

Fair enough, my wording was sloppy; I didn't distinguish between a
detectable violation and a non-detectable one, which was where my
mind was. The pseudo-code that I posted does surprisingly well against
the vast majority of test suites, most of which are exceedingly shallow.

> If you're inviting us to construct a test suite which can detect the
> faulty implementation that's not so hard, so beware :-)

Right, if you try to isend message(s) that exceed your total internal
buffer space, the fraud is revealed; it/they won't ever complete and you
can't cancel it/them. But for anything smaller, you can basically get away
with cheating because MPI is highly likely to eventually transmit the entire
message at some point. So when MPI comes back to you and says "sorry, too
late, I'm already past the point of no return", chances are that this will
ultimately become a true statement and the application is blissfully unaware
that MPI was really lying to it. Heh.

[ One of my favorite things to do when I was working on MPI was to dream of
ways to violate the standard, or at least the spirit of the standard.
Empirical evidence would suggest that this is a frighteningly common (and
very effective) form of therapy for MPI implementors. :-) ]

--
Eric Salo      Silicon Graphics      salo@sgi.com