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.

Sent from my PDA. No type good.

From: devel-bounces@open-mpi.org <devel-bounces@open-mpi.org>
To: devel@open-mpi.org <devel@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 :) )

Sent from my PDA.  No type good.

----- Original Message -----
From: devel-bounces@open-mpi.org <devel-bounces@open-mpi.org>
To: Open MPI Developers <devel@open-mpi.org>
Sent: Wed Feb 10 12:50:03 2010
Subject: Re: [OMPI devel] failure with zero-lengthReduce()andbothsbuf=rbuf=NULL

On 10 February 2010 14:19, Jeff Squyres <jsquyres@cisco.com> wrote:
> On Feb 10, 2010, at 11:59 AM, Lisandro Dalcin wrote:
>> > If I remember correctly, the HPCC pingpong test synchronizes occasionally by
>> > having one process send a zero-byte broadcast to all other processes.
>> >  What's a zero-byte broadcast?  Well, some MPIs apparently send no data, but
>> > do have synchronization semantics.  (No non-root process can exit before the
>> > root process has entered.)  Other MPIs treat the zero-byte broadcasts as
>> > no-ops;  there is no synchronization and then timing results from the HPCC
>> > pingpong test are very misleading.  So far as I can tell, the MPI standard
>> > doesn't address which behavior is correct.
>> Yep... for p2p communication things are more clear (and behavior more
>> consistens in the MPI's out there) regarding zero-length messages...
>> IMHO, collectives should be non-op only in the sense that no actual
>> reduction is made because there are no elements to operate on. I mean,
>> if Reduce(count=1) implies a sync, Reduce(count=0) should also imply a
>> sync...
> Sorry to disagree again.  :-)
> The *only* MPI collective operation that guarantees a synchronization is barrier.  The lack of synchronization guarantee for all other collective operations is very explicit in the MPI spec.

Of course.

> Hence, it is perfectly valid for an MPI implementation to do something like a no-op when no data transfer actually needs to take place

So you say that an MPI implementation is free to do make a sync in
case of Bcast(count=1), but not in the case of Bcast(count=0) ? I
could agree that such behavior is technically correct regarding the
MPI standard... But it makes me feel a bit uncomfortable... OK, in the
end, the change on semantic depending on message sizes is comparable
to the blocking/nonblocking one for  MPI_Send(count=10^8) versus

> (except, of course, the fact that Reduce(count=1) isn't defined ;-) ).

You likely meant Reduce(count=0) ... Good catch ;-)

PS: The following question is unrelated to this thread, but my
curiosity+laziness cannot resist... Does Open MPI has some MCA
parameter to add a synchronization at every collective call?

Lisandro Dalcin
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

devel mailing list