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 jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
