oneTBB icon indicating copy to clipboard operation
oneTBB copied to clipboard

limiter_node doesn't work in flow graph

Open andrewmabc opened this issue 3 years ago • 1 comments

Hi,

I have one problem about the usage of limiter_node. I create three nodes, i.e. source node, decoder node, and image processor node, which correspond to input_node, multifunction_node, and multifunction_node.

source node read video packets, and send video packets to its successor, i.e. decoder node. Then decoder node decodes video packets and output raw frames, and send raw frames to image processor node. I intent to limit the number of alive frames between decoder node and image processor node, and insert limiter_node between decoder node and image processor node. image processor node will send continue_msg to limiter_node's decrement port.

To verify limiter_node functions correctly, I use std::atomic to count the number of alive frame, where decoder node increases the count and image processor node decrease the count, and add extra sleep code in image processor node:

std::this_thread::sleep_for(std::chrono::milliseconds(some large time))

10 is set to limiter_node's threshold. When flow graph is running, I find std::atomic count is increasing. It seems limiter_node doesn't work. Is there something wrong with my usage of oneTBB?

Thanks!

regards

andrew

andrewmabc avatar Sep 13 '22 06:09 andrewmabc

@andrewmabc,

As I understood, you are using std::atomic counter to count the alive frames, decoder node increases the counter and processor node decreases the counter. The number of video packs that passes into the decoder is not limited, so for each frame decoded from the video pack, the counter would be increased. Then, the frame passes into the limiter node that limits the number of alive frames to be less than 10, so less then 10 frames passes into the processor node => atomic decreases less then 10 times. But the atomic simultaneously continues to increment because the number of packs passed into the decoder is not limited. So I would say that the increase of the atomic counter is expected in this case and it is not the correct way to verify the correctness of limiter_node. Please correct me if my understanding is wrong.

Also, did you consider using the non-unlimited concurrency into the image processor to limit the number of frames that are processed concurrently instead of limiter_node?

kboyarinov avatar Sep 15 '22 12:09 kboyarinov

How to get the number of messages on some edge between two nodes? Is there any effective way to get the value?

andrewmabc avatar Oct 07 '22 07:10 andrewmabc

@andrewmabc, there is no special API for getting the number of messages on the edge, because in fact there is no edge entity - it is just a logical relationship between the nodes. The only way I can propose to count is to place an additional node (e.g. function_node) that will count the messages and forward the message to further successors. If you would be able to share more details on your use-case when such counting is required, we will may be found the better solution.

kboyarinov avatar Nov 15 '22 11:11 kboyarinov

Please reopen this issue if you still have questions.

pavelkumbrasev avatar Jun 21 '23 12:06 pavelkumbrasev