Subject: Re: safe, unsafe and erroneous MPI programs

From: L J Clarke <[email-masked]>
Date: Thu, 4 Mar 93 11:55:00 GMT

I'm afraid that I must disagree with the notion of a global SECURE mode
as Paul has suggested, which can be switched on or off as the
programmer/user desires. 

In the first case, we really must think about programs being written to
include compositions of parallel libraries which have already been
written and determined to be correct and secure.  So the library writer
should have control of how the library communications are performed, and
this kind of "global change the semantics of everything" should be
avoided and discouraged. 

In the second case, once a module has correctly and safely been written
using secure communications I really don't think there will be so much
to "take advatage of" in use of system buffering.  All of my colleagues
at EPCC program in this way, and all of our library work is done in this
way.  Using the secure communications and blocking/nonblocking forms one
can write, without difficulty, secure and efficient software.  In fact,
more efficiently, in principle, since less memory copies of message data
are needed. 

Best Wishes
Lyndon

         /--------------------------------------------------------\
    e||) | Lyndon J Clarke    Edinburgh Parallel Computing Centre | e||) 
    c||c | Tel: 031 650 5021  Email: [email-masked]  | c||c 
         \--------------------------------------------------------/

---

From: Ian Glendinning <[email-masked]>
Date: Thu, 11 Mar 93 18:46:26 GMT

L J Clarke <[email-masked]> writes:

> This subset was provided by the SYNCHRONOUS completion mode proposed by
> Marc Snir, which was rejected at the last meeting.  I could not support
> the proposal because I do not believe that the completion mode proposed
> is actually what users want, and did not reflect common practice. 

It was with some dismay that I learned from the above message that the
SYNCHRONOUS completion mode had been dropped, having been unfortunately
unable to attend the last meeting, for which minutes have not yet been
posted.  Was this decision due to some awkward aspect of the precise
semantics in Marc's proposal, or was it just that the committee does not see
the need for any form of end-to-end synchronization mode at all?  If the
latter is the case then I am astounded.  In any case, I would strongly
advocate the inclusion of a synchronous, mode of communication, with both
blocking and non-blocking variants, for the same reasons elucidated by
Lyndon in a message posted before the February meeting:

> Given the above, I come to the conclusions:
>
> i)  MPI must contain unbuffered communications with blocking/nonblocking
> (irecv/isend/msgwait kinda thing) calls, for reliability and
> portability. 
>
> ii) If a goal of MPI is that existing applications using message passing
> interfaces (eg Express, PVM) should easily port to MPI, then MPI must
> also contain buffered comms. This seems to be a matter for the full
> committee, hence I have crossposted.

What went wrong at the February meeting?  I've not been very vocal on the mpi
mailing lists of late, having got behind in reading the mound of messages
arriving daily, but I'm back on top of it and hope to be contributing more
from now on.
   Ian
--
[email-masked]        Ian Glendinning
Tel: +44 703 593368                  Dept of Electronics and Computer Science
Fax: +44 703 593045                  University of Southampton SO9 5NH England