Subject: mpi-pt2pt: unsafe program? (short)

From: L J Clarke <[email-masked]>
Date: Thu, 8 Apr 93 16:43:20 BST

Dear MPI Colleagues

We have agreed that the following is an unsafe program.

Process 1                     Process 2               
---------                     ---------               
                                                      
Send to Process 2 Tag 0       Send to Process 1 Tag 0
Receive from Process 2 Tag 0  Receive from Process 1 Tag 0

So it seems that the following is also an unsafe program.

Process 1                     Process 2               
---------                     ---------               
                                                      
Send to Process 2 Tag 1       Receive from Process 1 Tag 2
Send to Process 2 Tag 2       Receive from Process 1 Tag 1

Does anyone disagree? 

Best Wishes
Lyndon

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

---

From: [email-masked]
Date: Fri, 09 Apr 93 09:44:22 MST

Lyndon asks if the program

Process 1                 Process 2

send(2, tag=1)            recv(1, tag=2)
send(2, tag=2)            recv(1, tag=1)

is unsafe. The answer is yes. With no buffering, process 2 cannot
complete the first recv, since process 1 has not sent the first msg yet
and process 1 cannot complete the first send, since process 2 has
not posted a receive for it. Even if buffering is available, the program
can still hang with large enough messages. The only safe way to
write this program is for one of the processes to post its first
operation in unblocked mode.

The basic reason for the strong requirement on a safe program is
that there is no good theoretical description of what a safe
program is in the presence of buffering. One possible weakening
would be to allow an MPI programmer to assume that when a message
is sent by one process to another, the second process can detect
if the message envelope has arrived (via probe), without blocking
the first process. Therefore, zero length messages would always
be safe.

Al Geist's comments are appropriate. MPI is defined so that
if you want to write a safe program you must assume no buffering,
which requires a LOT of programmer effort, and like the ready
receiver argument this programmer effort may indeed be counterproductive
on machines which do have significant buffering. The existing
constraint, while theoretically attractive, may be too limiting.
We can legislate whatever we want in meetings and build a useless
specification.

Further opinions:

  1) time-outs are a very bad idea. They add unlimited ways for things
    to go wrong. Remember that a timeout is a fixed threshold
    (unless you want to be able to change the timeout dynamically)
    and will always be chosen wrong in some situation. Your program
    will fail just when your boss or your customer is looking over
    your shoulder.
    
    There are usually better ways to accomplish the same thing without
    timeouts. For example, suppose the program has a process waiting for a task
    and there are no more tasks. Rather than using a time-out,
    a better way is to send a task request message that tells the
    waiting process to quit waiting for tasks.

    Timeouts are useful in network software which utilizes unreliable
    protocols, because they are the only way to detect certain classes
    of errors. MPI assumes reliable delivery of messages; therefore
    timeouts are inappropriate.

  2) ready-receiver is a moderately bad idea, (this is my
    own position) for reasons already posted by others on the net.

Mark Sears
Sandia National Laboratories

- ------- End of Unsent Draft

------- End of Forwarded Message