Visible to Intel only — GUID: GUID-F75C0357-DA84-433C-AD53-E70B24DDEADE
Package Contents
Parallelizing Simple Loops
Parallelizing Complex Loops
Parallelizing Data Flow and Dependence Graphs
Work Isolation
Exceptions and Cancellation
Containers
Mutual Exclusion
Timing
Memory Allocation
The Task Scheduler
Design Patterns
Migrating from Threading Building Blocks (TBB)
Constrained APIs
Invoke a Callable Object
Appendix A Costs of Time Slicing
Appendix B Mixing With Other Threading Packages
References
parallel_for_each Body semantics and requirements
parallel_sort ranges interface extension
TBB_malloc_replacement_log Function
Parallel Reduction for rvalues
Type-specified message keys for join_node
Scalable Memory Pools
Helper Functions for Expressing Graphs
concurrent_lru_cache
task_group extensions
The customizing mutex type for concurrent_hash_map
Waiting for Single Messages in Flow Graph
Visible to Intel only — GUID: GUID-F75C0357-DA84-433C-AD53-E70B24DDEADE
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.