Visible to Intel only — GUID: GUID-BA5B92AC-9E0B-4B4D-A431-05B909EACC73
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
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
Visible to Intel only — GUID: GUID-BA5B92AC-9E0B-4B4D-A431-05B909EACC73
Task Scheduler Bypass
Scheduler bypass is an optimization where you directly specify the next task to run. According to the rules of execution described in How Task Scheduler Works, the spawning of the new task to be executed by the current thread involves the next steps:
Push a new task onto the thread’s deque.
Continue to execute the current task until it is completed.
Take a task from the thread’s deque, unless it is stolen by another thread.
Steps 1 and 3 introduce unnecessary deque operations or, even worse, allow stealing that can hurt locality without adding significant parallelism. These problems can be avoided by using “Task Scheduler Bypass” technique to directly point the preferable task to be executed next instead of spawning it. When, as described in How Task Scheduler Works, the returned task becomes the first candidate for the next task to be executed by the thread. Furthermore, this approach almost guarantees that the task is executed by the current thread and not by any other thread.
Please note that at the moment the only way to use this optimization is to use preview feature of ``onepai::tbb::task_group`