Hi Steve,
On Mittwoch, 11. Oktober 2017 18:24:36 CEST Steve Petruzza wrote:
> Going back to the channels discussion, how do you know if a channel has been
> already registered or not?
>
> Look at the following code below (running with 2 localities):
> - they create or connect to the same channel name
> - if I introduce a delay in the receiver locality I get the following error:
>
> Assertion failed: (buffer_map_.empty()), function ~receive_buffer, file
> hpx_install/include/hpx/lcos/local/receive_buffer.hpp, line 101.
I think this error can be solved by having something akin to that:
int hpx_main(boost::program_options::variables_map& vm){
std::vector<hpx::naming::id_type> localities =
hpx::find_all_localities();
auto cid = hpx::get_locality_id();
if(cid%2==0)
{
hpx::lcos::channel<int> c(hpx::find_here());
c.register_as("name");
// Improve here with a custom neighbor barrier that only synchronizes
with
// the localities that connect for better scalability
hpx::lcos::barrier::synchronize();
c.set(3);
}
else
{
usleep(1000000); // delay
hpx::lcos::channel<int> c;
c.connect_to("name");
// Improve here with a custom neighbor barrier that only synchronizes
with
// the localities that connect for better scalability
hpx::lcos::barrier::synchronize();
hpx::lcos::barrier::synchronize();
hpx::future<int> p = c.get();
p.get();
}
}
When calling it with --hpx:run-hpx-main that scheme should scale reasonably
well. To make it scale better, you should us a custom barrier instead of the
global, system-wide one.
>
> Here is the sample code:
> —————————
>
>
> void spmd_int(DataFlow::ShardId cid){
> if(cid%2==0){
> hpx::lcos::channel<int> c(hpx::find_here());
> c.register_as(“name");
> c.set(3);
> }
> else{
> usleep(1000000); // delay
> hpx::lcos::channel<int> c;
> c.connect_to("name");
> hpx::future<int> p = c.get();
> p.get();
> }
> }
>
>
> int hpx_main(boost::program_options::variables_map& vm){
> std::vector<hpx::naming::id_type> localities =
> hpx::find_all_localities();
>
> int loc_count = 0;
> for(auto loc: localities){
>
> spmd_int_action act;
> hpx::async(act, loc, loc_count);
>
> loc_count++;
> }
> }
>
> —————————
>
>
> What is happening here?
> If I add a
> c.connect_to("name");
>
> to the the same task that does the registration (after
> c.register_as(“name");) it works, but I don’t like it (and in my actual
> application I still get this error).
>
> More in general, when you have many of this channels at scale, do you think
> is better to use a register_as/connect_to mechanism or to pass alle the
> necessary channels to each locality at the beginning when I do the initial
> SPMD spawn?
>
> Thanks,
> Steve
>
> > On 11 Oct 2017, at 14:53, Steve Petruzza <[email protected]> wrote:
> >
> > Thanks Hartmut, it all makes sense now.
> >
> >> On 11 Oct 2017, at 14:51, Hartmut Kaiser <[email protected]>
wrote:
> >>>> I think I’ve found a workaround.
> >>>>
> >>>> If I use a typedef as following:
> >>>>
> >>>> typedef std::vector<char> vec_char;
> >>>>
> >>>> HPX_REGISTER_CHANNEL(vec_char);
> >>>>
> >>>> It works, but if I try to use directly:
> >>>> HPX_REGISTER_CHANNEL(std::vector<char>)
> >>>>
> >>>> this gives me the error I reported before.
> >>>> The issue might be in the expansion of the macro HPX_REGISTER_CHANNEL.
> >>>
> >>> Yes, that confirms my suspicion. I will have a looks what's going on.
> >>
> >> Doh! The problem is that the (literal) parameter you give to the macro
> >> has to conform to the rules of a valid symbol name, i.e. no special
> >> characters are allowed (no '<', '>', etc.). Sorry, this has to be
> >> documented properly somewhere, and I forgot to mention it in the first
> >> place.
> >>
> >> The 'workaround' you propose is the only way to circumvent problems.
> >> There is nothing we can do about it.
> >>
> >> Also, wrt your comment that everything is working if you use
> >> hpx::lcos::local::channel instead - this is not surprising. The local
> >> channel type is representing a channel which can be used inside a given
> >> locality only (no remote operation, just inter-thread/inter-task
> >> communication), hence its name. Those channels don't require the use of
> >> the ugly macros, thus there is no problem.
> >>
> >> HTH
> >> Regards Hartmut
> >> ---------------
> >> http://boost-spirit.com
> >> http://stellar.cct.lsu.edu
> >>
> >>> Thanks!
> >>> Regards Hartmut
> >>> ---------------
> >>> http://boost-spirit.com
> >>> http://stellar.cct.lsu.edu
> >>>
> >>>> Steve
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 10 Oct 2017, at 18:38, Steve Petruzza <[email protected]>
> >>>> wrote:
> >>>>
> >>>> Sorry, regarding the version that I am using it is the commit of your
> >>>>
> >>>> split_future for vector:
> >>>> Adding split_future for std::vector
> >>>>
> >>>> - this fixes #2940
> >>>>
> >>>> commit 8ecf8197f9fc9d1cd45a7f9ee61a7be07ba26f46
> >>>>
> >>>> Steve
> >>>>
> >>>>
> >>>>
> >>>> On 10 Oct 2017, at 18:33, Steve Petruzza <[email protected]>
> >>>> wrote:
> >>>>
> >>>> hpx::find_here()
_______________________________________________
hpx-users mailing list
[email protected]
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
