Enim,
Before going into all these efforts to implement a new function, let me
describe what is there already and that you can use to achieve something
similar. It will not be exactly what you describe, because changing a
particular collective algorithm dynamically on a communicator might is not
as
+1 on what George says.
In general, the only MPI collective operation that *forces* an explicit, global
synchronization is MPI_Barrier. Specifically: no process can exit the barrier
until all processes have entered the barrier.
In you example (MPI_Bcast), none of the non-root processes can exi
In this case the MPI_Bcast will act as a synchronization point, the slaves will
be blocked in the call until the master do the operation.
george.
On Nov 18, 2012, at 15:54 , Sandra Guija wrote:
> Hello,
> Could someone be kind and explain me the MPI_Bcast when is call by all the
> other pr
Thank you all for replying, I think I know where to start now. I will
post when I get more information :)
/Xin
On 09/27/2011 05:49 PM, Christian Siebert wrote:
Hi Xin,
I think you are referring to the multicast functionality of TIPC, right?
That would be great if it works properly. You might
On Sep 27, 2011, at 5:43 AM, Xin He wrote:
> sorry that it takes so long for paper works of TIPC BTL. Hopefully I can get
> some feedback this week.
Great.
> However, I would like to do some work while waiting. For future work, I would
> like to add TIPC_broadcast
> to support MPI_Bcast. But a
Xin,
The collective calls are handled by the collective framework (mca/coll). You
can export only the function you want (MPI_Bcast in your example) from your
collective component.
george.
On Sep 27, 2011, at 05:43 , Xin He wrote:
> Hi all,
>
> sorry that it takes so long for paper works of
