Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] failure withzero-lengthReduce()andbothsbuf=rbuf=NULL
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2010-02-11 10:29:45


On Feb 11, 2010, at 10:04 AM, George Bosilca wrote:

>> I misparsed your reply. Yes, bcast(1) *can* sync if it wants to. I don't have a spec handy to check if bcast(0) is defined or not (similar to reduce). If it is, then sure, it could sync as well.
>
> I have to disagree here. There are no synchronization in MPI except MPI_Barrier.

There's no synchronization *guarantee* in MPI collectives except for MPI_BARRIER.

> At best, a bcast(1) is a one way synchronization, as the only knowledge it gives to any rank (except root) is that the root has reached the bcast. No assumptions about the other ranks should be made, as this is strongly dependent on the underlying algorithm, and the upper level do not have a way to know which algorithm is used. Similarly, a reduce(1) is the opposite of the bcast(1), the only certain thing is at the root and it means all other ranks had reached the reduce(1).

I don't think we're disagreeing here. All I'm saying is that BCAST *can* synchronize; I'm not saying it has to. For example, using OMPI's sync coll module is perfectly legal because the MPI spec does not disallow synchronizing for collectives. MPI only *requires* synchronizing for BARRIER.

Right?

> Therefore, we can argue as much as you want about what the correct arguments of a reduce call should be, a reduce(count=0) is one of the meaningless MPI calls and as such should not be tolerated.

No disagreement there. I wish we could error on it. "Darn the IMB torpedos! Full speed ahead!!" ;-)

-- 
Jeff Squyres
jsquyres_at_[hidden]
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/