Newsgroups: comp.parallel.mpi
From: sanders@ira.uka.de (Peter Sanders)
Subject: Re: Fairness, When not, Why not, ...
Organization: Universitaet Karlsruhe, Germany
Date: 11 Feb 1996 10:30:47 GMT
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <SANDERS.96Feb11113047@i90s25.ira.uka.de>

In article <DMKHxt.GEu@undergrad.math.uwaterloo.ca> eddemain@neumann.uwaterloo.ca (Erik Demaine) writes:
 >     (Peter Sanders)
 >  : > The MPI standard (section 3.5) states that message delivery is
 >  : > not guaranteed to be fair in the sense that a message may
 >  : > never be delivered if it is continously overtaken by
 >  : > other messages. I think this situation is also being referred to
 >  : > as "livelock" in the literature.
 >
 >    (Eric Salo)
 >  : Correct me if I am wrong, but I believe you are confusing fairness with
 >  : in-order delivery. MPI messages are non-overtaking, meaning that if
 >  : process A sends two identical messages to process B, they will arrive
 >  : in the order that they were sent. What MPI does *not* specify is the
 >  : order of arrival for messages from *different* senders.
This was a misunderstanding, I was talking about a situation
where there are really several senders involved.
 >
 >  (Eric Demaine)
 >  In the case where there are different senders, you can use MPI_Waitsome or
 >  MPI_Testsome to avoid livelock.  See the MPI standard.

That is an interesting answer. In the MPI-standard there is an
"advice to users" that MPI_Waitsome can be used to avoid starving
senders. But this does only works if MPI guarentees that 
all messages evenually emerge from the NETWORK even
if there is dense traffic from other sources. 
(Correct me if I am wrong)
My understanding was that the remark in section 3.5 allows exactly
this sloppy behavior of the network system.

Now let us assume that livelock is really only a matter of
the MPI-internal protocol and the underlying network is
required to be fair. Let me modify my original question for
this case:
- What MPI implementations do NOT guarantee fairness when
  MPI_Recv ist used with MPI_ANY_SOURCE?
- What is the performance penalty of using 
  an outstanding receive for all processors and
  MPI_Waitsome compared to MPI_Recv with MPI_ANY_SOURCE?
  In particular when there are many processors. Say 1024.
- What was the rationale for not guaranteeing fairness
  if it is only a question of MPI-internal protocol.
  I think guaranteeing fairness is easy to implement
  on this level so that I would not really understand
  this design decision.  

Regards,

Peter Sanders, University of Karlsruhe

