• 2021.4
  • 09/27/2021
  • Public Content
Contents

Using limiter_node

One way to limit resource consumption is to use a limiter_node to set a limit on the number of messages that can flow through a given point in your graph. The constructor for a limiter node takes two arguments:
limiter_node( graph &g, size_t threshold )
The first argument is a reference to the graph it belongs to. The second argument sets the maximum number of items that should be allowed to pass through before the node starts rejecting incoming messages.
A limiter_node maintains an internal count of the messages that it has allowed to pass. When a message leaves the controlled part of the graph, a message can be sent to the decrement port on the
limiter_node
to decrement the count, allowing additional messages to pass through. In the example below, an
input_node
will generate
M
big objects. But the user wants to allow at most three big objects to reach the
function_node
at a time, and to prevent the
input_node
from generating all
M
big objects at once.
graph g; int src_count = 0; int number_of_objects = 0; int max_objects = 3; input_node< big_object * > s( g, [&]( oneapi::tbb::flow_control& fc ) -> big_object* { if ( src_count < M ) { big_object* v = new big_object(); ++src_count; return v; } else { fc.stop(); return nullptr; } } ); s.activate(); limiter_node< big_object * > l( g, max_objects ); function_node< big_object *, continue_msg > f( g, unlimited, []( big_object *v ) -> continue_msg { spin_for(1); delete v; return continue_msg(); } ); make_edge( l, f ); make_edge( f, l.decrement ); make_edge( s, l ); g.wait_for_all();
The example above prevents the
input_node
from generating all
M
big objects at once. The
limiter_node
has a threshold of 3, and will therefore start rejecting incoming messages after its internal count reaches 3. When the
input_node
sees its message rejected, it stops calling its body object and temporarily buffers the last generated value. The
function_node
has its output, a
continue_msg
, sent to the decrement port of the
limiter_node
. So, after it completes executing, the
limiter_node
internal count is decremented. When the internal count drops below the threshold, messages begin flowing from the
input_node
again. So in this example, at most four big objects exist at a time, the three that have passed through the
limiter_node
and the one that is buffered in the
input_node
.

Product and Performance Information

1

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.