Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

oneTBB: code update and passing functors

AG7
Beginner
815 Views

Dear All,

I'm looking for an advice regarding passing functors to flow_graph. I have a LOT of nicely working and tested filter-like classes which I've been using in older version of the tbb::pipeline. So all of them have call operator defined (with const attribute).

Now I would like to use those classes and pass them/functors to graph. Issue is, all classes have only move constructors, while tbb::graph insists on copy constructors, which are explicitly deleted.
What are my options? I feel like I'm missing some basic C++ skills here. I tried std::cref but all that either does not compile or run.
I would appreciate any advise how to re-use the codebase on oneAPI.

A.

0 Kudos
1 Solution
Mark_L_Intel
Employee
372 Views

Hello,


Please look at


https://github.com/oneapi-src/oneTBB/issues/235


https://github.com/oneapi-src/oneTBB/issues/138


quoting from issue #235 above:


"

It is quite difficult to enable move support everywhere because some nodes (e.g. broadcast_node) are supposed to forward messages to multiple successors. In other word, in some cases copy semantics is unavoidable.

In any case, we can consider where move semantics is applicable and extend such cases (e.g. input of function nodes and buffering nodes). Thank you for the idea.

"



View solution in original post

9 Replies
GouthamK_Intel
Moderator
779 Views

Hi Artur,

Thanks for reaching out to us

We are working on your issue, we will get back to you soon.


Regards

Goutham


AG7
Beginner
772 Views

Thank you, Goutham.

I will really appreciate any feedback on this. If I could use functor/class with move constructor than transition from TBB to oneTBB would be seamless, while otherwise modifying and testing (!) tens of thousands of lines of code.

regards,

A.

James_T_Intel
Moderator
764 Views

There is currently a feature request to support move constructors at https://github.com/oneapi-src/oneTBB/issues/138, is this relevant for you?


As a workaround, are you able to set up pointers to your classes that could be copied instead?


AG7
Beginner
754 Views

James,

I think, no. My problem is more trivial, and as I wrote maybe I'm just missing some C++ fundamentals. I attach here a snippet to show what I'm trying to do. I just have hundreds of similar classes/filters/functors, with call operators, each of them classes are then std::unique_ptr. If there is a way to "feed" such functors to graph I'd be a happy man.

A.

Mark_L_Intel
Employee
462 Views

Hello,

 

can you look at https://docs.oneapi.io/versions/latest/onetbb/tbb_userguide/Working_on_the_Assembly_Line_pipeline.ht... -- the example constructs the pipeline (of filters) using functors as well. 

AG7
Beginner
408 Views

Mark,

 

thank you for the suggestion. Assembly line example, was the first one I used years ago to develop the pipeline implementation of the processing steps. Now I want to move that to GRAPH and one api implementations and faced the issue I described  in my original (first post) and sample code.

The issue in essence is that I deleted all copy constructors on my classes while it seems they are required by graph. I was looking for an advise whether there is any way to avoid redesigning hundreds of classes which work perfectly fine for pipeline in the graph implementation and do it only with move constructors.

 

A.

Mark_L_Intel
Employee
373 Views

Hello,


Please look at


https://github.com/oneapi-src/oneTBB/issues/235


https://github.com/oneapi-src/oneTBB/issues/138


quoting from issue #235 above:


"

It is quite difficult to enable move support everywhere because some nodes (e.g. broadcast_node) are supposed to forward messages to multiple successors. In other word, in some cases copy semantics is unavoidable.

In any case, we can consider where move semantics is applicable and extend such cases (e.g. input of function nodes and buffering nodes). Thank you for the idea.

"



View solution in original post

AG7
Beginner
341 Views

Mark,

 

thank you again for clarifying this to me. I appreciate your help and time. If there is any voting system for TBB features I'd sign up for enabling move constructor in input node, at the very least.

Thanks again,

 

A.

Mark_L_Intel
Employee
299 Views

Hello,


I already got in touch with TBB developers and pointed them to your new request.


I'd also encourage you to file an issue through GitHub channel similar to what others did (referenced in my previous post).


Your post certainly helps to establish better understanding of why expanding role of move constructors in TBB Flow Graph is desirable. So thank you for your contribution!


Reply