Visible to Intel only — GUID: GUID-B6CEBBDE-855C-4A17-A07C-D69CA1E4B70F
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
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
parallel_phase Interface for Task Arena
Deduction Guides for blocked_nd_range
Visible to Intel only — GUID: GUID-B6CEBBDE-855C-4A17-A07C-D69CA1E4B70F
Use Concurrency Limits
To control the number of instances of a single node, you can use the concurrency limit on the node. To cause it to reject messages after it reaches its concurrency limit, you construct it as a “rejecting” node.
A function node is constructed with one or more template arguments. The third argument controls the buffer policy used by the node, and is by default queueing. With a queueing policy, a function_node that has reached its concurrency limit still accepts incoming messages, but buffers them internally. If the policy is set to rejecting the node will instead reject the incoming messages.
template < typename Input, typename Output = continue_msg, graph_buffer_policy = queueing > class function_node;
For example, you can control the number of big objects in flight in a graph by placing a rejecting function_node downstream of an input_node, as is done below:
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(); function_node< big_object *, continue_msg, rejecting > f( g, 3, []( big_object *v ) -> continue_msg { spin_for(1); delete v; return continue_msg(); } ); make_edge( s, f ); g.wait_for_all();
The function_node will operate on at most three big objects concurrently. The node’s concurrency threshold that limits the node to three concurrent invocations. When the function_node is running three instances concurrently, it will start rejecting incoming messages from the input_node, causing the input_node to buffer its last created object and temporarily stop invoking its body object. Whenever the function_node drops below its concurrency limit, it will pull new messages from the input_node. At most four big objects will exist simultaneously, three in the function_node and one buffered in the input_node.