Re: [OMPI devel] failure withzero-lengthReduce()andbothsbuf=rbuf=NULL

[Eugene Loh]

Jeff Squyres (jsquyres) 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. My previous point was that barrier is the only collective that is *required* to synchronize.  From: devel-boun...@open-mpi.org <devel-boun...@open-mpi.org> To: de...@open-mpi.org <de...@open-mpi.org> Sent: Thu Feb 11 07:04:59 2010 Subject: Re: [OMPI devel] failure withzero-lengthReduce()andbothsbuf=rbuf=NULL Where does bcast(1) synchronize? (Oops on typo - if reduce(1) wasn't defined, that definitely would be bad :) ) To clarify my comments on this thread... There are causal synchronizations in all collectives.  E.g., a non-root process cannot exit a broadcast before the root process has entered.  The root process cannot exit a reduce before the last non-root process has entered.  Stuff like that.  Those were the only syncs I was talking about and the only sync that the HPCC pingpong test relied on.  I wasn't talking about full barrier sync. Anyhow, a causal sync for a null collective is different.  There is no data forcing synchronization.  Unlike point-to-point messages, there isn't even header meta data.  So what behavior is required in the case of null collectives? Incidentally, in what respect is reduce(0) not defined?  It would seem to me that it would be an array of 0 length, so we don't need to worry about its datatype or contents.