|
Boost Users : |
Subject: Re: [Boost-users] mpi: sending/receiving different types
From: Hicham Mouline (hicham_at_[hidden])
Date: 2010-12-07 03:41:27
> -----Original Message-----
> From: boost-users-bounces_at_[hidden] [mailto:boost-users-
> bounces_at_[hidden]] On Behalf Of Riccardo Murri
> Sent: 07 December 2010 08:20
> To: boost-users_at_[hidden]
> Subject: Re: [Boost-users] mpi: sending/receiving different types
>
> On Mon, Dec 6, 2010 at 6:01 PM, Hicham Mouline <hicham_at_[hidden]>
> wrote:
> > About the broadcast() function, I obviously have many types of
> messages to send, would you rather:
> >
> > 1. send a broadcast with just an int (like a tag) to tell which
> broadcast is following next
> >
> > or
> >
> > 2. construct a virtual base class my_mpi_broadcast , derive all the
> sendable broadcasts from it, from sender, send actual instance of
> derived from my_mpi_broadcast, and at receiver, can the mechanism
> reconstruct for me the derived class? (with boost::serialization)
> >
>
> I'm not sure I understand this question: mpi::broadcast() works like a
> send+recv in one call: one MPI rank (the *root*) sends, the others
> receive.
>
> Any data that is allowed in send() can be used in a broadcast(); in
> particular, if you have classes with Serialization support, you send()
> or broadcast() them with no additional effort.
>
> Best regards,
> Riccardo
> _______________________________________________
Hello
During a sequence of communication, the slave processes don't know what type
to get broadcast of, next.
What should be the T in the call to broadcast.
1. the root sends a tag for the T to tell the receivers I will broadcast you
this and this. This means 2 broadcast each time
2. the root sends directly a reference to a base class of anything sendable,
then the receivers construct the derived classes on reception with
broadcast. The T is then the base class type.
3. I just thought of using boost::variant<> over all the possible types.
rds,
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net