Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
For the latest information on Intel’s response to the Log4j/Log4Shell vulnerability, please see Intel-SA-00646
2407 Discussions

Creating my own node classes based on tbb flow graph


Hello everyone.

I've just started using tbb flow graphs and I've got some questions.

Actually, I need more nodes in it and as I understand I can build them by inheriting my class from tbb::flow::graph_node, tbb::flow::sender, etc. Am I right?

Being more concrete, I need two nodes.

First one should be a sender node, which takes data asynchronously from UDP port using, say, boost::asio and then pushes this data into the flow graph.

Second one is some kind of a functional node, but it should not respond to every incoming message. It should receive some portions of data, then it should process this data and then push out a single portion. For example, we can receive 10 integer numbers, add them all together and then push out the result.

Can anyone help me with designing these nodes? Or can anyone show me some articles on designing my own nodes?

I would be greatful for your answers.

0 Kudos
1 Reply

Hi Oleg,

In my opinion, your do not need special nodes in the algorithm:

  1. For asynchronous operations you can create your own thread and use async_node. This node provides a "gateway" interface that is used to submit work to a flow graph from an external activity.
    P.S. I do not recommend using other graph nodes (e.g. source_node or function_node) in this case because asynchronous activity can block the TBB worker thread and reduce overall parallelism.
  2. The second case when you need to gather several messages into one message can be solved with multifunction_node. It uses an explicit interface to put message to successors. I.e. the body can process and gather the required number of messages and put a pack to successors only when necessary. It should be noted, by default, multifunction_node can be called in parallel for multiple incoming messages. You need either explicit synchronization inside the body or a "serial" policy to prevent parallel execution.
    Perhaps, you want to consider join_node if the number of messages to be packed into one message is known at compile time.

In any case, you can really create your own nodes by inheriting them from senderreceiver and graph_node. However, it is a sophisticated approach that we are would not like to recommend. Moreover, we are thinking about deprecation of this approach because of its complexity. The simpler method is to develop your own node is a composite_node that aggregates other nodes into one node. But I recommend you to consider existing nodes if they suit your needs.