Newsgroups: comp.parallel.mpi
From: tony@aurora.cs.msstate.edu (Tony Skjellum)
Subject: Re: Broadcasting and ordering
Organization: Mississippi State University
Date: 28 Apr 1995 00:01:51 GMT
Message-ID: <3npb9f$i5i@NNTP.MsState.Edu>

MPI2 committee is considering this, but not very favorably.  I am working
on a proposal for the collective extensions chapter that will define 
the semantics simply as follows:

a) MPI_MCAST must have the same properties as a sequential send loop
b) Regular send must be used to receive it 
c) Special multicast hardware can be used to implement it, provided a) and b)
are satisfied.

MCAST has terrible properties:
	-- progress rule violation
	-- deadlock potential
	-- order violation imminent

and has been criticized and discussed extensively by forum.  It is also argued
that its true performance characteristics are illusory, because it assumes
that processes are lined up, as they might  be for a MPI_BCAST.  Earlier
argumentation has appeared on this on this newsgroup.

So, MPI_MCAST(buffer, count, type, tag, comm) is roughly the syntax we will propose
for sender, with obvious meaning of arguments, receivable by all.  For those who
use this as a vanilla technology, it will be there, for those who want performance,
they have to ask for a good underlying network that has multicast hardware.

It is not clear if this will pass, but it might, because of above restrictions.

I will also propose a variation:
    MPI_MCAST_SUBGROUP(buffer, count, type, tag, group, comm)
which I expect not be accepted.  It will broadcast to subgroup of comm's group.
This would be a nicety, but is very different semantically from other MPI functions.
The syntactic sugar argument might win, and force us to stay only with MCAST.  Clearly,
MPI_MCAST_SUBGROUP subsumes MPI_MCAST as a special case, but not necessarily without
more checking.

-Tony Skjellum
-----------------------------

Jeff McAffer (jeff@is.s.u-tokyo.ac.jp) wrote:

: A couple questions:

: 1) Is there a way of broadcasting a message from one process to all
: others in a comm group but have it so that the arriving message
: appears as a point-to-point message?  As I understand the MPI spec
: (dated 5/5/94), MPI_BCAST is a collective operation and must be called
: by all members of the comm group.  That is, receivers do not receive
: via normal (p2p) receive operations.  

: I realize that no synchronization is implied but in my system,
: receivers cannot tell apriori whether the next message is a broadcast
: or p2p, or from where it will be coming.  Also, it appears that
: collective operations are spec'd to be blocking.  This means that I
: can't just poll to see what is there (which I wouldn't like to do
: anyway).

: 2) Perhaps I missed it but I did not see if MPI defines message
: ordering.  Does the spec say anything about this?

: I would appreciate your comments on this.  Thanks

: JEff

: --
: ato de, |m        -- Why do women always leave the toilet seat down?

--
Anthony Skjellum, Asst. Professor, MSU/CS/ERC, Ph: (601)325-8435; FAX: (601)325-8997.
Mosaic: http://www.erc.msstate.edu/~tony; e-mail: tony@cs.msstate.edu
Maxim:  "There is no lifeguard at the gene pool." - C. H. Baldwin
	.	.	.	.	.	.	.	.      .      .
Mosaic info on applying to MSU: see http://msuinfo.ur.msstate.edu/prospect.htm (not html)
	.	.	.	.	.	.	.	.      .      .

