If resources are constrained by a number of available CPUs rather than by a mask (e.g., via cgroups), two test cases in test_constrained_requests required reconsideration. This patch reworks some of the checks in the test. Also, it adds further TODOs to address later.
This fixes various issues when building TCM benchmarks using Intel LLVM C++ compiler. The issues include:
- `max_index` is unused variable in case of a release build.
- Destructor in `fractal_runtime` is not defined as virtual while there are virtual methods.
- `~fractal_runtime_tbb` has exception specification that is more lax than the one of the base class.
- `num_frames` is initialized before functor `f` in `fractal_runtime`.
- `num_threads` is unused.
Signed-off-by: Fedotov, Aleksei <aleksei.fedotov@intel.com>
MSVC is pessimistic about the number of bytes to be written into the array during its initialization. The 'permit_size' is always greater than the warning shows. So, suppressing it.
Although the library doesn't include any interface changes but the package includes the new HWLOC version. So, it was decided to increase the minor version and keep it in sync with the interface version for better debuggability from internal users perspective. We might change this approach in future, especially if TCM is open sourced.
* Add new SDL-recommended flags - /LTCG, /sdl, /Gy as well as /INCREMENTAL:NO and /GL
---------
Co-authored-by: Aleksei Fedotov <aleksei.fedotov@intel.com>
Due to assignment to the `permit_handle` in `tcmRequestPermit` function,
test always logged that the permit request was made on an existing
permit handle.
The test has incorrect assumption and is too white-boxish. This patch makes it less white-boxish, but still assumes that TCM negotiates minimal number of permits to satisfy minimum of requested resources.
This patch makes an assumption in TCM that the requesting thread is going to be registered with the permit being obtained, and, therefore, makes TCM searching for less by one resource in case the thread that requesting a permit is already registered with another, and, hence, was given a resource previously.
---------
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
Co-authored-by: Aleksei Fedotov <aleksei.fedotov@intel.com>
Implemented a simple Fuzz function that set TCM env variables with random values. Validate that TCM is working by executing basic test.
---------
Signed-off-by: pavelkumbrasev <pavel.kumbrasev@intel.com>
Co-authored-by: Ilya Isaev <ilya.isaev@intel.com>
Removed FCFS.
Removed unused helper functions.
Removed unused system_topology functions which was there due to borrowing from TBBBind.
Added get_permit_state function to clean up code a little bit.
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
Co-authored-by: Aleksei Fedotov <aleksei.fedotov@intel.com>
There is a missed spot in TCM which testing didn't cover: releasing of lazy inactive permit. Permit didn't give back its resources and it could lead to not getting granted concurrency for newer permits.
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
When using -static-intel option, Intel Compiler statically links internal libraries like libimf. Their symbols are exported automatically which can lead to unexpected issues due to mixed symbols in scenarios when multiple libraries with same dependencies are present. To eliminate this issue, --exclude-libs ALL link option is used.
Co-authored-by: Fedotov, Aleksei <aleksei.fedotov@intel.com>
This patch slightly changes logic of permit's deactivation to make it work in more "lazy" manner. This means that in case where there is no demand for resources (in this case having other active or pending permits), deactivation of the permit will work like idle - keeping the resources and just change a state of the permit. This allows to quickly activate this permit later.
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
Co-authored-by: Aleksei Fedotov <aleksei.fedotov@intel.com>
TCM is now DISABLED by default, thus replace opt-out envvar by opt-in one. Remove "-beta" suffix from the version. Add "BUILD TIME" and "COMMIT ID" information to be available with TCM_VERSION=1
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
oneTBB should not know anything about HWLOC interfaces, but is aware about TCM. Therefore, where
necessary it should rely on either TBBBind or TCM instead, not HWLOC. Since TBBBind does not define
the type representing the CPU mask, replace all the references of mask from HWLOC to mask from TCM.
The test manually load TBBbind. Previously the test repeated the TBBbind load procedure from TBB library, so potentially the test could load a TBBbind different from one loaded by the TBB library. After the change no new load is performed, only search between already loaded dynamic libraries. This resolves the potential issue mentioned above.
Do not postpone the notifications for more than just a few unsuccessful attempts to find a non-local task, in order to avoid skewed results in profiling tools.
* Limited-resource RFC.
* Add to introduction
* Add question about constrained template use
* More work on introduction
* Primarily whitespace cleanup.
* Standardize thread-(un)safe
* Add blurb on C++20 support
* Updates to serialization RFC
* Incomplete version of sequence diagram
* Expand on limited resources
* Update README.md
* Update image
* Update README.md
* Minor updates
* Add performance analysis to README
* Whitespace cleanup
* Adjust heading levels
* Minor edits to text
* Adjust levels one more time
* Final editing pass before PR
* Remove unused plantuml files
* Adjust PR based on Mike's and Konstantin's suggestions/questions
* Adjust GitHub markdown
* Adjust GitHub markdown...again
* Update proposal based on @akukanov's suggestion
* Include graph diagram of analyzed workflow
* Use png instead
* Show graph with limiters
---------
Co-authored-by: Kyle Knoepfel <knoepfel@fnal.gov>
* examples: common: add_benchmark_target macro
New `add_benchmark_target` macro to use it with benchmark targets where post-execution data transformation is needed to summarize results, convert output to .csv files, etc. This feature requires `gawk` utility installed.
* examples: Tachyon, Primes, Sudoku: Add benchmark data post-processing
Add two new build targets to the Tachyon, Primes, and Sudoku examples to execute them for benchmarking with suggested parameters and optional .csv report file.
Signed-off-by: Dmitrii Golovanov <dmitrii.golovanov@intel.com>
* Move measurements class to measurements.hpp
Move class `measurements` from utility.hpp to its own file
measurements.hpp to simplify its use at example applications
eliminating duplicate declarations on include.
Adjust `seismic` example accordingly.
* examples: Extend class 'measurements'
Extend class `measurements`:
* keep initial number of iterations.
* stop() to return duration from the last start().
Add optional prefix and suffix at utility::report_relative_error().
* examples: tachyon: Add relative error estimation
Extend Tachyon example with additional option to execute
rendering several times and calculate relative error to
estimate rendering performance reliability.
* examples: primes: Add relative error estimation
Extend the Primes example `n-of-repeats` execution mode to
calculate relative error for each of the parallel threads
execution block (`n-of-threads`), so it is now possible to
measure their performance reliability.
* examples: sudoku: Add repeats and relative error
Extend Sudoku example with additional option to repeat solution
several times and calculate relative error to estimate
performance reliability.
Signed-off-by: Dmitrii Golovanov <dmitrii.golovanov@intel.com>
* Update test matrix
* Update ubuntu runner for non-testing jobs as well
* Use common version of clang-format
* Fix typos found by codespell
* Configure codespell
* Disable formatting on a piece of code
Emscripten uses static linking, so we should explicitly request a static TBB library instead of
* explicitly asking for shared (current instructions)
* using the default, i.e., shared
Both of the above get overridden with multiple warnings.
* Enable CTAD for blocked_rangeNd since C++17
* Fix constraits test failure
* Extend implementation with tests and explicit deduction guide
* Remove unnecessary helper function
* Simplify the deduction guide
* Add deduction guide for blocked_range type
* Enable CTAD for blocked_rangeNd since C++17
* Fix constraits test failure
* Fix merging issue
* Add new deduction guides and test
* Update copyright years
* Update copyright years
* Save progress
* Apply review comments + introduce preview macros
* Fix fancy value
* Add single C array support
---------
Co-authored-by: Ruslan Arutyunyan <ruslan.arutyunyan@intel.com>
* Add CTAD RFC
* Fix examples
* Add information about the braced-init-list limitation
* Retarget the RFC to experimental
* Add exit criterias + cleanup
* Add one more limitation
* Add link
In case of pthread_attr_getstack() returns np_stack_size = 1MB,
- calculated stack_base = stack_limit + stack_size(default: 4MB)
- real stack_base = stack_limit + np_stack_size(1MB)
stack_base is wrong because calculated with 4MB stack size.
Due to this wrong stack_base, task_dispatcher::can_steal() can be always false.
It causes abnormal long loop in task_dispatcher::receive_or_steal_task().
Correct this problem using np_stack_size instead of stack_size.
Signed-off-by: Bongkyu Kim <bongkyu7.kim@samsung.com>
* To allow compiling with -fvisibility=hidden flag, GCC visibility attributes (with value "default") should be set.
* Enforce exporting unsafe_wait symbols on MacOS
Signed-off-by: Vladislav Shchapov <vladislav@shchapov.ru>
getObjectSize should not return values bigger then 2^16-1.
We are assigning it's return value, which is 32 bit to 16 bit one,
so it is good to assert it anyway.
page_size variable was set to -1024 if hugepages was not used, while
being unsigned type. It did not matter as it was not used, when
hugepages are not used, but it is better to set it just to 0.
local_wait_for_all function seems to be a common spot for both external and worker threads to perform thread registration. So, basically whole implementation is to simply call register_thread only on first thread enter to local_wait_for_all and unregister_thread on last thread exit.
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
In this version of the ucrtbase.dll, the assembly of the _msize
function has changed.
The first instruction of this function is a relative jump (0xE9)
followed by a 4-byte offset. This offset has changed, but we can
safely assume that 0xE9 followed by any offset value is correct,
especially since we have special handling for the 0xE9 instruction in
the InsertTrampoline() function.
The 0xCC is an INT 3 instruction, so it's a free space to use.
On Windows systems with multiple processor groups, HWLOC x86 backend might interfere with process affinity mask leading applications trying to set process affinity mask to fail.
---------
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
* Add `threading_control::is_any_other_client_active()` to verify if other arenas are requesting workers.
* Add hybrid CPU detection at initialization.
* On non-hybrid CPUs, make workers block for 1ms before leaving the arena, unless
- more work becomes available in the arena (-> unblock and stay in the arena);
- other arenas are requesting workers (-> unblock and leave the arena immediately).
Signed-off-by: Dmitri Mokhov <dmitri.n.mokhov@intel.com>
Signed-off-by: pavelkumbrasev <pavel.kumbrasev@intel.com>
Add cmake option TBB_BUILD_APPLE_FRAMEWORKS to build oneTBB as Apple Frameworks.
This is needed to be able to create iOS compatible app bundles which need to embed TBB as framework, as using dylibs is prohibited by Apple.
Co-authored-by: Ilya Isaev <ilya.isaev@intel.com>
Initialize/destroy Controls during acquire/release resources stage to avoid unexpected problems with global objects initialization order.
Signed off by: Santiago Ospina De Los Ríos <sospinar@gmail.com>
Currently TBB attempts a find package and excludes the entire build part of the CMake setup when *either* `TBB_FIND_PACKAGE` *or* `TBB_DIR` are defined. This is an issue when using `FetchContent` with `OVERRIDE_FIND_PACKAGE` as CMake declares `TBB_DIR` to equal `${CMAKE_BINARY_DIR}/CMakeFiles/pkgRedirects/`.
Code owners are automatically requested for review when someone opens
a pull request that modifies code that they own. Code owners are
not automatically requested to review draft pull requests.
Signed-off-by: Krzysztof Filipek <krzysztof.filipek@intel.com>
After stealing, current arena must be taken into account while selecting
next arena to prevent deadlock. Arena index is passed explicitly for that.
Signed-off-by: Alexandr Konovalov <alexandr.konovalov@intel.com>
Currently enumerable_thread_specific.h inclusion breaks std::min and
std::max usage due to macro spreading from windows.h.
Signed-off-by: Alexandr Konovalov <alexandr.konovalov@intel.com>
Bump of Bazel version to 7.0.0
Add MODULE.bazel to support Bazel's new system of handling dependencies (bzlmod)
Remove .bazelrc (config of out-of-source build is not needed or a best practice)
- add `Threads` dependency to installed CMake config for static builds only
- based on #912 by @p12tic including reviewer comments from @ilya-lavrenov and @isaevil
- resolves#1145
Signed-off-by: Liam Keegan <liam@keegan.ch>
Bump cmake version to 3.5 to avoid this deprecation message:
CMake Deprecation Warning at CMakeLists.txt:15 (cmake_minimum_required):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
Signed-off-by: Julien Schueller <schueller@phimeca.com>
This fixes issue #1210 by adding a default virtual destructor for tbb::detail::r1::control_storage.
Signed-off-by: Elias Engelbert Plank <plank.elias.engelbert@gmail.com>
"Test priority inversion" test case manually increases threads' priority (including main thread) to test priority inversion problem but never restore it. That could lead to busy-waiting inside oneTBB on RT Linux kernels which is not expected. This patch restores previous priority after the test case completes.
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
Co-authored-by: Konstantin Boyarinov <konstantin.boyarinov@intel.com>
* Add a CMake option: `TBB_FUZZ_TESTING` (default: off)
* Add a `test_fuzzing`, which uses libFuzzer to fuzz all the environment variables and launches `test_task` each time.
Signed-off-by: Dmitri Mokhov <dmitri.n.mokhov@intel.com>
By accident, the define was called WIN32 - should be _WIN32.
The string #if _WIN32 can be found more than 100 times in this repo - #if WIN32 only one time.
It breaks the Bazel build of oneTBB on Windows (bazel build //...).
Add TCM support in oneTBB. oneTBB can coordinate with Intel(R) OpenMP on CPU resources usage to avoid excessive oversubscription when both runtimes are used within a process.
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
Signed-off-by: pavelkumbrasev <pavel.kumbrasev@intel.com>
Co-authored-by: Ilya Isaev <ilya.isaev@intel.com>
Co-authored-by: Aleksei Fedotov <aleksei.fedotov@intel.com>
env/vars scripts now support different layouts (for example, bin/ or redist/ on Windows, lib/<arch> or lib<arch_suffix>/ on Linux). Also modulefiles now rely on lib/ and lib32/ for library path, not on lib/intel64/gcc4.8 or lib/ia32/gcc4.8
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
Co-authored-by: Olga Malysheva <olga.malysheva@intel.com>
Shifting by a negative amount has an undefined behavior.
A shift amount must not be negative.
It fixes the Coverity issues: 449477 and 913889.
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
Size in alignToBin() must not be less than the StepFactor (8).
It fixes the Coverity issues: 449474 and 913880.
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
This commit fixes the issue when test_malloc_pools TestFixedBufferPool
fails sporadically on test_malloc_pools.cpp:437
utils::NativeParallelFor( p, FixedPoolUse(p, pool, MAX_OBJECT/p/2,1) );
The main problem was that threads were not aware of cleanup operations
done by SoftCachesCleanup() and HardCachesCleanup() functions.
So while one thread was doing a cleanup, the second one
returns ENOMEM as it couldn't find any memory to allocate in the
backend (this test creates fixedSizePool)
The change adds additional flags and counters that indicate cleanup
operation is in progress, allowing the thread to wait for those
operations to complete before deciding if there is free memory to
allocate or not and return this information to the caller.
In the scenario reproduced by the test, memory for the allocation can
be reclaimed from the LOC. This operation happens in the
loc.cleanAll() or loc.regularCleanup functions called respectively, by
hardCachesCleanup() or softCachesCleanup() functions.
In those functions, free memory is removed from LOC and added to the
backend bin. Between those operations, other threads are unaware that
this memory block is free and returns ENOMEM to the user.
To fix this problem, this patch adds two flags to indicate that
cleanup (soft or hard) is in progress, and threads should wait before
returning NULL to the user.
But there was one more problem: backend::clean() function.
This function removes memory from the bins to try to release or
coalesce it. The problem is that other threads were not aware of
this operation. It causes a 'funny' situation when:
Thread 1: Performs HardCachescleanup function
Thread 2: wait "waitTillBlockReleased()"
Thread 1: Returns memory from LOC
Thread 2: exits waitTillBlockReleased() as it detected new memory in
backend
Thread 1: starts backend::clean() - removes memory from the bin to try
coalesce it
Thread 2: Fail memory allocation as there is no free block in
bins, and returns ENOMEM
Thread 1: Finish coalescing and return memory back to bins
To resolve this problem, this patch adds a counter which allows
threads to detect when clean operation is done so that the threads
will wait for the complition of there is no memory available.
Signed-off-by: Łukasz Plewa <lukasz.plewa@intel.com>
"for loop" without condition and without iterator is not a great
solution for code readability. For simple infinite loop "while loop" is
much more readable solution.
Signed-off-by: Łukasz Plewa <lukasz.plewa@intel.com>
With this patch user may build TBBBind on macOS and be able to use tbb::info namespace to obtain high-level information about the system and limit task_arena accordingly (without actual CPU binding since such functionality is not supported on macOS via HWLOC).
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
Nested parallelism use case where TBB outer loop has a relatively small amount of work comparing to the amount of OpenMP work on the nested level is of particular importance to the TCM project, since it exposes the main problem with oversubscription, which resolution justifies such projects as TCM.
This patch adds such a use case into synthetic set of TCM benchmarks.
Besides this, the patch also makes other small improvements to avoid type conversion issues and makes the OpenMP executor to not specifying the "num_threads" clause on the loop pragma if user did not specify the concurrency of the OpenMP executor explicitly.
Add two new microbenchmarks:
ubench_constrained.cpp - perfect nested microbenchmarks using NUMA constraints
ubench_perfect_nested - "perfect nesting" case
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
Co-authored-by: Aleksei Fedotov <aleksei.fedotov@intel.com>
Prevent an incorrect optimization by ICL 19.0 (fixed in ICL 19.1) with VS 2017 stdlib with inline-level=1 (/Ob1) that resulted in premature object destruction inside `std::unordered_set`.
Signed-off-by: Dmitri Mokhov <dmitri.n.mokhov@intel.com>
The OpenMP can adjust the number of threads when it re-activates the rigid concurrency permit after it was involuntary deactivated while being in IDLE state.
Therefore, TCM should try satisfying initially requested amount of resources as much as possible for such permits.
The patch puts an order on the resources redistribution. It starts by trying to satisfy the request with available resources. If these are not enough, then it takes back IDLE resources (even from rigid concurrency permits), and only after that negotiates resources from ACTIVE permits.
For non-rigid concurrency IDLE permits the negotiation happens until required amount of resources for these permits is still satisfied. If further negotiation is required, the permits are moved to INACTIVE state. The rigid concurrency permits in IDLE state are transferred to INACTIVE state without negotiation. Later on if such rigid-concurrency permit tries to activate, the TCM tries to match the amount of resources the permit was given before it was deactivated.
Besides that the patch also reveals a couple of issues with support of constrained requests and a data-race in `updated_permit` function, which have been fixed, corresponding regression tests were added.
The patch also allows automatic inference of the request parameters if a client did only automatic request initialization.
---------
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
Signed-off-by: Fedotov, Aleksei <aleksei.fedotov@intel.com>
Co-authored-by: Isaev, Ilya <ilya.isaev@intel.com>
Co-authored-by: Pavel Kumbrasev <pavel.kumbrasev@intel.com>
trylockblock() locks mutex in the current element and mutex in right
neighbor, so we have to free both locks.
Signed-off-by: Łukasz Plewa <lukasz.plewa@intel.com>
*.pdb files are shipped in GH prebuilt binaries but they are not installed when trying to do make install
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
When using setuptools version > 60 there is issue with cutting names of install files when passing build directory with ./.
Workaround is to use intermediate directory instead of ./.
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
MacOS version of code tries to open unversioned binaries of runtime plugins unlike on Linux. This patch aligns this behavior.
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
This patch replaces get_filename_component by find_library which is more flexible and can find libraries in multiple locations if PATH_SUFFIXES argument is specified.
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
* Add runtime support for disabling RTLD_DEEPBIND by default to enable Address Sanitizer.
The Address Sanitizer will not work properly if the RTLD_DEEPBIND flag is passed to dlopen. The accepted workaround is to build your code without passing RTLD_DEEPBIND to dlopen when using the Address Sanitizer
Signed-off-by: sarathnandu <sarath.nandu.ramachandran.nair@intel.com>
* Revert "Do not run the test_malloc_new_handler test under Valgrind (#1077)"
This reverts commit 727601afc0.
* Do not intercept allocation symbols in tbbmalloc tests (fix)
Valgring intercepts all allocation symbols with its own by default,
so it disables using tbbmalloc. In case of tbbmalloc tests
intercept allocation symbols only in the default system libraries,
but not in any other shared library or the executable
defining public malloc or operator new related functions.
With this change the test_malloc_new_handler test works correctly,
so let's revert #1077.
This patch fixes three tbbmalloc tests:
- test_malloc_new_handler,
- test_malloc_atexit,
- test_malloc_overload
that have not passed under Valgrind so far.
Fixes: #1080Fixes: #1081
Ref: #1077
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
---------
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
Add the NOMEMCHECK option to the tbb_add_test() function.
Do not run the test_malloc_new_handler test under Valgrind,
because this test throws an exception in new/new[],
but Valgrind cannot throw exceptions and so is aborting instead.
Fixes: #1075
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
This PR adds an automatic labeling feature to OneTBB.
The purpose of this commit is to add initial support
and label PRs changing anything related to tbbmalloc.
Signed-off-by: Krzysztof Filipek <krzysztof.filipek@intel.com>
In version.h, TBB_INTERFACE_VERSION_MINOR is defined as TBB_INTERFACE_VERSION%1000/10. This test works for single-digit minor versions, but starts failing, e.g., for TBB_INTERFACE_VERSION_MINOR=12110 (where minor version should be 11).
Signed-off-by: Dmitri Mokhov <dmitri.n.mokhov@intel.com>
/DWIN32 is automatically put on command line by CMake but isn't the standard predefined macro to detect Windows.
Instead, use _WIN32 || _WIN64 to detect Windows platform which is done in many other places in the code.
Co-authored-by: Fedotov, Aleksei <aleksei.fedotov@intel.com>
If constraints are initialized by default but has the mask set, the value for max_concurrency should
be set to oversubscribed concurrency of the mask to be able to allocate as maximum resources as
possible and on the given mask, hence avoid violating compatibility rule.
Test resource balancing had incorrect assumption that the callback was invoked after rigid concurrency request was made. Most likely, this was left untouched after FAIR RDS was changed to negotiate only required resources.
We did not notice that because the check for this did not propagate its status to the "public".
* WIP: Add test for the TCM request that was initialized by default
Also, add number of platform resources without oversubscription in tests and rename total_number_of_threads constaint.
Support for printing meta info when TCM_VERSION is set to 1. Added runtime functions to get TCM version.
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
Co-authored-by: Aleksei Fedotov <aleksei.fedotov@intel.com>
Also, add the test that models the behaviour of oneTBB, where worker threads are detached.
Signed-off-by: pavelkumbrasev <pavel.kumbrasev@intel.com>
Co-authored-by: Fedotov, Aleksei <aleksei.fedotov@intel.com>
The deep copying helps in resolving possible crashes and data races issues.
The deep copying includes the copying of the constraints and their masks in case they were specified
by the client.
Signed-off-by: Fedotov, Aleksei <aleksei.fedotov@intel.com>
Remove static qualifier from containers in renegotiate_permits()
Since containers become function locals and they are destroyed when execution goes out of scope, remove unnecessary clearing out on exit from renegotiate_permits()
---------
Signed-off-by: pavelkumbrasev <pavel.kumbrasev@intel.com>
Co-authored-by: Fedotov, Aleksei <aleksei.fedotov@intel.com>
These files do not have the executable bit set in their file mode, and
they only need to be run as modules, not as executable scripts.
Signed-off-by: Jonathan Wakely <jwakely@fedoraproject.org>
Signed-off-by: Jonathan Wakely <jwakely@fedoraproject.org>
The use of std::string results in the additional new line symbol when printing the mask on the
console, which makes its representation poor. Additionally, the size of the mask was computed
incorrectly, since 'hwloc_bitmap_weight' function returns the number of turned ON bits, instead of
the number of characters needed to represent the mask in the text form.
Signed-off-by: Fedotov, Aleksei <aleksei.fedotov@intel.com>
* Make typedef input_type protected so that it's not exposed in join_node public interface
Signed-off-by: Deepanjan Biswas <deepanjan.biswas@formlabs.com>
* Make join_FE_node typedefs private
Signed-off-by: Deepanjan Biswas <deepanjan.biswas@formlabs.com>
* Use a different name for the tuple size template argument
Signed-off-by: Deepanjan Biswas <deepanjan.biswas@formlabs.com>
* Use the new template argument name as the base class argument. This builds on macOS
Signed-off-by: Deepanjan Biswas <deepanjan.biswas@formlabs.com>
Signed-off-by: Deepanjan Biswas <deepanjan.biswas@formlabs.com>
* Replacing files to update ittnotify to tag v3.23.0
* codespell error elimination
* Adding back changes made by PR #917
* Adding back changes made by #850
* Changing copyright
* ITT RELEASE RESOURCES MACRO
* Fixing copyright issue
* Address changes for frontend.cpp
ASAN report an error if we tries to downcast a misaligned address.
To avoid it, we need to check if an address is valid before casting it.
Here is the ASAN error:
/home/runner/work/mold/mold/third-party/tbb/src/tbb/../../include/tbb/../oneapi/tbb/concurrent_hash_map.h:446:23: runtime error: downcast of misaligned address 0x000000000003 for type 'tbb::detail::d2::hash_map_iterator<tbb::detail::d2::concurrent_hash_map<std::basic_string_view<char, std::char_traits<char>>, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>>>, tbb::detail::d1::tbb_hash_compare<std::basic_string_view<char, std::char_traits<char>>>, tbb::detail::d1::tbb_allocator<std::pair<const std::basic_string_view<char, std::char_traits<char>>, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>>>>>>, std::pair<const std::basic_string_view<char, std::char_traits<char>>, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, st0x000000000003: note: pointer points here
<memory cannot be printed>
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/runner/work/mold/mold/third-party/tbb/src/tbb/../../include/tbb/../oneapi/tbb/concurrent_hash_map.h:446:23
Signed-off-by: Rui Ueyama <ruiu@cs.stanford.edu>
Signed-off-by: Rui Ueyama <ruiu@cs.stanford.edu>
Current implementation of parallel_for_each may call destructors for uninitialized objects when using Input iterator and count of elements in block is less than max_block_size. This is UB and can lead to incorrect memory access in some scenarios.
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
* Restoring Windows DLL details information
This restores the detailed information in the Windows dll. This has been absent from the revamped oneTBB.
* Update CMakeLists.txt
Enabling build of Windows resource file.
* Update CMakeLists.txt
Updating copyright year
* Add files via upload
Adding Windows resource file for tbbmalloc
* Update CMakeLists.txt
Enabling building of tbbmalloc resource file
* Add files via upload
Adding tbbmalloc_proxy Windows resource file
* Update CMakeLists.txt
Enabling the build of tbbmalloc_proxy resource file
* Add files via upload
Adding tbbbind resource file
* Update CMakeLists.txt
Enabling tbbbind resource file build
* Update resource.rc
Product name update in resource file
* Update CMakeLists.txt
Restricting resource build to default tbbbind
* Add files via upload
Replacing resource.rc with tbb.rc to conform with other dlls (tbbmalloc, tbbbind etc)
* Update CMakeLists.txt
Update from resource.rc to tbb.rc
* Update CMakeLists.txt
Updating copyright year
* Update CMakeLists.txt
Updating the copyright year
* Update tbb.rc
Removing "Windows" from the product name and sourcing the version from version.h
* Update tbb_bind.rc
Removing "Windows" from the product name and sourcing the version info from version.h
* Update tbbmalloc.rc
Removing "Windows" from the product name and sourcing the version info from version.h
* Update tbbmalloc_proxy.rc
Removing "Windows" from the product name and sourcing the version info from version.h
There are sporadic fails with tbb4py test (test.py). The problem is that some test cases rely on the fact, that submitted async work will not finish until calling get with timeout. To do there is a call for time.sleep in functor submitted. Sporadically, expected result is not happening (like OSX example in issue) so to prevent that, the blocking is used.
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
* Fix concurrent_queue::clear not to require default ctor
* Suppress warning about the unused variable in release mode
* Fix the conformance test not to rely on the additional item in dtor
* template->class in template template parameter
* Rework the fix
* Remove unnecessary flag from internal pop method
* Minor clean-up
* Add exception macros to the test
* Add whitespace
* Fix PR comments
* Fix logic for a build with no exceptions
The existing regex strips all occurrences of the given string from
`${CMAKE_CXX_FLAGS}`, regardless of whether it is just a substring of a
flag. For instance, `-Werror=format-security` gets truncated to
`=format-security`.
The new regex makes sure that only whole words get replaced.
Signed-off-by: Christoph Erhardt <github@sicherha.de>
* Windows compilation issues: prevent min/max problem, secure warnings and etc.
* Windows compilation issues: C4101: unreferenced local variable.
* Windows compilation issues: C4018: signed/unsigned mismatch and bool issue.
* Windows compilation issues: C4018: signed/unsigned mismatch and bool issue. Part II
* Windows compilation issues: suppress compile warnings.
* Windows compilation issues: suppress compile warnings. Part II
* Windows compilation issues: adds helpers to simplify test code.
* Windows compilation issues: temporary comment static_asserts - not pass on MSVC.
* Corrects test name in log.
* Simplify test framework.
* Changes logging output.
* Windows compilation issues: don't use static assert for structures with bit-fields on Windows.
* Review changes.
* Correct project compile options.
* Windows compilation issues: correct tests.
* Windows compilation issues: avoid compile warnings.
* Windows compilation issues: correct Linux build.
* Prevent error: unused variable.
* Style correction.
* Rework CMake configuration: creates common part as separate file.
* Suppress compile warnings for test on Linux.
* Suppress compile warnings for test on Linux. Update.
* Corrects tests to avoid missing-field-initializers warning on Linux.
* Review changes.
* Integrate new test helpers.
* Review changes: migrate to system processing include file not found in CMake.
There is a need for global switch for TCM. The idea is to have an envariable that, when set to anything except for zero, makes the TCM to drop connection attempts.
In order to have reasonable performance this variable is read only once - at the library load time when its globals are initialized. Because of that it is impossible to write single test that changes the variable during the test and makes connection attempts to the TCM. Therefore, the patch adds three identical tests, but modifies the environment these tests are invoked in.
The patch addresses issue #6.
New topic about Lazy initialization pattern and how it can be implemented using oneapi::tbb::collaborative_call_once has been added.
Signed-off-by: Ilya Isaev <ilya.isaev@intel.com>
* Document a way to flow graph can be attached to arbitrary task_arena
task_arena interface provides mechanisms to guide tasks execution within the arena by
setting the preferred computation units or restricting part of computation units. In some
cases, you may want to use mechanisms within a flow graph.
Signed-off-by: Serov, Vladimir <vladimir.serov@intel.com>
Co-authored-by: Aleksei Fedotov <aleksei.fedotov@intel.com>
Co-authored-by: Alexandra Epanchinzeva <alexandra.epanchinzeva@intel.com>
It currently prevents compilation under musl:
```
[ 90%] Building CXX object src/tbbmalloc_proxy/CMakeFiles/tbbmalloc_proxy.dir/proxy.cpp.o
/__w/mimalloc-bench/mimalloc-bench/extern/tbb/src/tbbmalloc_proxy/proxy.cpp:263:26: error: return type 'struct mallinfo' is incomplete
263 | struct mallinfo mallinfo() __THROW
| ^
compilation terminated due to -Wfatal-errors.
``
TBB resumable tasks are implemented using getcontext() and setcontext()
on Unix-like systems. These functions are deprecated in the recent
versions of POSIX and may not exist. musl libc does not provide these
functions.
There's unfortunately no way to detect musl (musl intentionally do not
define macros like `__MUSL__`), so __TBB_RESUMABLE_TASKS is defined if
`__GLIBC__`. glibc-compatible libc's such as uClibc defines `__GLIBC__`,
so it should work as a catch-all condition.
Signed-off-by: Rui Ueyama <ruiu@cs.stanford.edu>
Test for coverage cancel function of oneapi::tbb::flow::overwrite_node::register_predecessor_task
Signed-off-by: Serov, Vladimir <vladimir.serov@intel.com>
Co-authored-by: Aleksei Fedotov <aleksei.fedotov@intel.com>
In order to reduce GOT size on MIPS that leads to linkage errors (relocation truncated to fit: R_MIPS_GOT_PAGE) in debug, tbb::flow::join_node testing was split into separate files.
Signed-off-by: Ilya Isaev <ilya.isaev@intel.com>
* Fix race in conformance_task_arena
- call observe(false) in the derived observer destructor
- do the same for all observers in the tests
Signed-off-by: Anton Potapov <anton.potapov@intel.com>
* Fix container::range_type behavior in case of empty containers
* Remove test that violates the spec
* Fix range.begin to point to a value node
Signed-off-by: Alexei Katranov <alexei.katranov@intel.com>
* Remove first_value_node from empty
Co-authored-by: Alexei Katranov <alexei.katranov@intel.com>
* making task_group_context::is_proxy race free
using special value of task_group_context::my_state (former my_lifetime_state) to avoid
races on task_group_context::my_traits
the race was on task_group_context::my_traits member
- it was read by the is_proxy() member during task spawning
- it was written to in bind_to() function on first task spawning
- some renamings
- task_group_context::my_state -> my_may_have_children
- task_group_context::my_lifetime_state ->my_state
- task_group_context::lifetime_state -> state
- removed unused enum values
Signed-off-by: Anton Potapov <anton.potapov@intel.com>
Co-authored-by: Pavel Kumbrasev <pavel.kumbrasev@intel.com>
Explicit enabling of task_group related preview features was removed, in favor of logic in test/common/config.h
Signed-off-by: Anton Potapov <anton.potapov@intel.com>
- use same arena for task_group::run() and task_group::wait() methods
- use single thread environment for test stability
Signed-off-by: Anton Potapov <anton.potapov@intel.com>
Class template inheritance doesn't work well with function-local types
Move class definition to global scope
Signed-off-by: Serov, Vladimir <vladimir.serov@intel.com>
* Added optimized x86 atomic_fence for gcc-compatible compilers.
On x86 (32 and 64-bit) any lock-prefixed instruction provides sequential
consistency guarantees for atomic operations and is more efficient than
mfence.
We are choosing a "lock not" on a dummy byte on the stack for the following
reasons:
- The "not" instruction does not affect flags or clobber any registers.
The memory operand is presumably accessible through esp/rsp.
- The dummy byte variable is at the top of the stack, which is likely
hot in cache.
- The dummy variable does not alias any other data on the stack, which
means the "lock not" instruction won't introduce any false data
dependencies with prior or following instructions.
In order to avoid various sanitizers and valgrind complaining, we have to
initialize the dummy variable to zero prior to the operation.
Additionally, for memory orders weaker than seq_cst there is no need for
any special instructions, and we only need a compiler fence. For the relaxed
memory order we don't need even that.
This optimization is only enabled for gcc up to version 11. In gcc 11 the
compiler implements a similar optimization for std::atomic_thread_fence.
Compilers compatible with gcc (namely, clang up to 13 and icc up to 2021.3.0,
inclusively) identify themselves as gcc < 11 and also benefit from this
optimization, as they otherwise generate mfence for
std::atomic_thread_fence(std::memory_order_seq_cst).
Signed-off-by: Andrey Semashev <andrey.semashev@gmail.com>
* Removed explicit mfence in atomic_fence on Windows.
The necessary instructions according to the memory order argument
should already be generated by std::atomic_thread_fence.
Signed-off-by: Andrey Semashev <andrey.semashev@gmail.com>
* Removed memory order argument from atomic_fence.
The code uses memory_order_seq_cst in all call sites of atomic_fence,
so remove the argument and simplifiy the implementation a bit. Also, renamed
the function to make the memory order it implements apparent.
Signed-off-by: Andrey Semashev <andrey.semashev@gmail.com>
Moving task_group_exptensions out of the preview
- moved all but :
- is_inside_task
- scheduller bypass
- replaced exceptions with asserts for undefined behavior
- made some flags in the tests non-atomic for TSAN to raise a flag if
implementation is incorrect
Signed-off-by: Anton Potapov <anton.potapov@intel.com>
Co-authored-by: Ilya Isaev <ilya.isaev@intel.com>
Co-authored-by: Alex <alexei.katranov@intel.com>
Exclude non-glibc linux systems along with android
Fixes
src/tbb/dynamic_link.cpp:417:29: error: use
of undeclared identifier 'RTLD_DEEPBIND' | flags = flags | RTLD_DEEPBIND;
| ^
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This uses the standard allocator for allocating and freeing memory with
higher alignment requirements instead of the hand-rolled implementation.
Signed-off-by: Andrey Semashev <andrey.semashev@gmail.com>
* Fixed incorrect definitions of assignment operators in associative containers.
This fixes incorrect return types of assignment operators imported from
base classes. Other than copy and move assignment operators, which are
generated by the compiler even if imported with a using-declaration,
the imported operators will be returning a reference to the base class
instead of the derived class.
Fixes https://github.com/oneapi-src/oneTBB/issues/372.
Signed-off-by: Andrey Semashev <andrey.semashev@gmail.com>
Signed-off-by: Ilya Isaev <ilya.isaev@intel.com>
collaborative_call_once is moved from preview. Also added conformance_collaborative_call_once test file
Signed-off-by: Ilya Isaev <ilya.isaev@intel.com>
Fixed compilation error on Windows while compiling with IntelLLVM compiler: "#include resolved using non-portable Microsoft search rules"
Signed-off-by: Ilya Isaev <ilya.isaev@intel.com>
Synchronization order of calls function market::adjust_demand should
be made for arena, not for the market itself.
Signed-off-by: Serov, Vladimir <vladimir.serov@intel.com>
Co-authored-by: pavelkumbrasev <pavel.kumbrasev@intel.com>
This patch fixes issue with reference leak reported by test_global_control and test_tbb_fork on static build.
Signed-off-by: Isaev, Ilya ilya.isaev@intel.com
Co-authored-by: Alex <alexei.katranov@intel.com>
In scope of this patch TBB_BUILD and TBBMALLOC_BUILD options were added. It was done to support scenarios when we are testing without tbbmalloc. It allows us to cover place where we fail to link with tbbmalloc and start using std_cache_aligned_allocate/deallocate.
Signed-off-by: Ilya Isaev ilya.isaev@intel.com
1. Using thread_local for non-pointer types instead of tbb::detail::r1::tls
2. Replace magic-value with valid pointer
Signed-off-by: Serov, Vladimir <vladimir.serov@intel.com>
* Use imported target instead of variables during the HWLOC search using pkg-config
* Remove redundant code + rephrase the description
* Fix the indentation
* Rework testing
Signed-off-by: Kochin Ivan <kochin.ivan@intel.com>
Co-authored-by: Alexey Veprev <alexey.veprev@intel.com>
* Bind internal pinning observer lifetime to the internal arena
* Control the tbbbind system_topology lifetime manually
* Fix entry point name
* Apply review remarks:
* rename platform_topology to system_topology inside tbbbind
* other minor fixes
Signed-off-by: Kochin Ivan <kochin.ivan@intel.com>
- Fix incorrect assert in concurrent_hash_map implementation
- Fix incorrect asserts in global_control implementation
- Fix exception pointer inside task_group_context
- Rework racy asserts in test_flow_graph_whitebox
- Improve test_eh_algorithm to work with sanitizers
- Disable memory limit test in test_malloc_compliance
- Add lifetime asserts in collaborative_call_once
- Rework backref space in tbbmalloc to use atomics
- Fix a lifetime issue in utils::SpinBariier
- Some tests were disabled
Signed-off-by: Alexei Katranov <alexei.katranov@intel.com>
Co-authored-by: pavelkumbrasev <pavel.kumbrasev@intel.com>
The current synchronization in task_group_context made by more then one atomic variable. This code hard to debug and each ThreadSanitizer report in this code usual require unreadable workaround to fix it. To improve correctness and readability of this code it was decided to rewrite synchronization using mutex.
Signed-off-by: Ilya Isaev ilya.isaev@intel.com
Memory leak has been caused by ThirdParty library.
Adding LSAN suppression list for filter known issues.
Signed-off-by: Serov, Vladimir <vladimir.serov@intel.com>
*For some reason, GCC does not instrument tbbmalloc with TSan when lto is enabled.
*Fix race in internal allocator on handler pointer initialization.
*Simplify checks in conformance_parallel_for
Signed-off-by: Alexei Katranov <alexei.katranov@intel.com>
* Use right affinity mask type during tests compilation on FreeBSD
* Disable priority inversion testing on FreeBSD
* Fix test_malloc_compliance compilation
* Add TODO, remove redundant blank line
Signed-off-by: Kochin, Ivan <kochin.ivan@intel.com>
* Added support for QCC (QNX GNU Compiler)
* Enable source code compilation with non-Linux Unix systems with special focus on QNX.
Signed-off-by: promero <promero@mathworks.com>
* Upgrade from HWLOC 2.4 to HWLOC 2.5
* Introduce tbbbind_2_5 library
* Remove tbbbind_2_4 library
* Use the HWLOC_TOPOLOGY_FLAG_RESTRICT_TO_CPUBINDING topology flag (introduces as a part of HWLOC 2.5) to restrict topology discovering to process binding
* Fix testing on Linux
* Apply review comments
* Improve wording: variable -> substring
* Use right tbbbind version for incompatible hwlocs test
* Rework option semantic
* Update README.md for CMake
* Rework readme
* Update cmake/README.md
Signed-off-by: Kochin, Ivan <kochin.ivan@intel.com>
Co-authored-by: Aleksei Fedotov <aleksei.fedotov@intel.com>
Reverting ASAN fix for test_malloc_regression #415
Turn off memory leaks test in test_malloc_regression test case
Signed-off-by: Serov, Vladimir <vladimir.serov@intel.com>
* Fix a typo in chmap, temporary rename concept range
* Rename range concept, add workaround for Windows
* Reimplement with respect to prospective destructors
* Fix fibonacci
* Fix dlopen flags for loading tbbmalloc and rml
* Rework macro definition approach
* Use correct macro name
Signed-off-by: Kochin, Ivan <kochin.ivan@intel.com>
Out Of Memory conditions simulated in the ReallocParam test breaking ASAN, so skip this case under it.
Signed-off-by: Alexei Katranov <alexei.katranov@intel.com>
* Solve the issue with different incompatible hwlocs in one executable
* Support macOS and Windows
* Fix flags on Windows and MacOS
* Try to fix Windows compilation
* Add warning suppression
* Rename the CMake variable
* Fix the RTLD_DEEPBIND flag placement condition
* Improve naming
* Change flags logic
* Suppress MSVC 2015 warning: 'int': forcing value to bool 'true' or 'false'
Signed-off-by: Kochin Ivan <kochin.ivan@intel.com>
message(STATUS"Dependency signature verification during dynamic linking in run-time is ENABLED.")
elseif(NOTDEFINEDTBB_VERIFY_DEPENDENCY_SIGNATURE)
message(WARNING
"Dependency signature verification during dynamic linking in run-time is disabled by "
"default. This may lead to security vulnerabilities. See installation section in "
"oneTBB documentation for more details.")
else()
message(STATUS"Dependency signature verification during dynamic linking in run-time is DISABLED")
endif()
option(TBB_VERIFY_DEPENDENCY_SIGNATURE
"Verify signature of a dependency during its dynamic linking at run-time on Windows*"OFF)
endif()
if(NOTDEFINEDBUILD_SHARED_LIBS)
set(BUILD_SHARED_LIBSON)
endif()
if(NOTBUILD_SHARED_LIBS)
if(NOTDEFINEDCMAKE_POSITION_INDEPENDENT_CODE)
set(CMAKE_POSITION_INDEPENDENT_CODEON)
endif()
message(WARNING"You are building oneTBB as a static library. This is highly discouraged and such configuration is not supported. Consider building a dynamic library to avoid unforeseen issues.")
endif()
@@ -116,6 +171,14 @@ if (NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
As an open source project, we welcome community contributions to oneAPI Threading Building Blocks (oneTBB). This document explains how to participate in project conversations, log bugs and enhancement requests, and submit code patches to the project.
## Licensing
Licensing is very important to open source projects. It helps ensure the software continues to be available under the terms that the author desired. The oneTBB project uses the [Apache 2.0 License](https://github.com/uxlfoundation/oneTBB/blob/master/LICENSE.txt), a permissive open source license that allows you to freely use, modify, and distribute your own products that include Apache 2.0 licensed software. By contributing to the oneTBB project, you agree to the license and copyright terms therein and release your own contributions under these terms.
Some imported or reused components within oneTBB use other licenses, as described in [third-party-programs.txt](https://github.com/uxlfoundation/oneTBB/blob/master/third-party-programs.txt). By carefully reviewing potential contributions, we can ensure that the community can develop products with oneTBB without concerns over patent or copyright issues.
## Prerequisites
As a contributor, you'll want to be familiar with the oneTBB project and the repository layout. You should also know how to use it as explained in the [oneTBB documentation](https://uxlfoundation.github.io/oneTBB/) and how to set up your build development environment to configure, build, and test oneTBB as explained in the [oneTBB Build System Description](cmake/README.md).
## Pull Requests
You can find all [open oneTBB pull requests](https://github.com/uxlfoundation/oneTBB/pulls) on GitHub.
### Before contributing changes directly to the oneTBB repository
* Make sure you can build the product and run all the tests with your patch.
* For a larger feature, provide a relevant test.
* Document your code. The oneTBB project uses reStructuredText for documentation.
* If your documentation has code samples or examples, place them into the corresponding example folder.
* Update the copyright year in the first line of the changing file(s).
For example, if you commit your changes in 2025:
* the copyright year should be `2005-2025` for existing files
* the copyright year should be `2025` for new files
* Submit a pull request into the master branch. You can submit changes with a pull request (preferred) or by sending an email patch.
Code changes that are known or suspected to break support for any currently supported hardware are not allowed.
Contributors should make a reasonable effort to ensure compatibility with these platforms. If a contribution
inadvertently affects hardware support, the community will work together to address and resolve the issue.
Continuous Integration (CI) testing is enabled for the repository. Your pull request must pass all checks before it can be merged. We will review your contribution and may provide feedback to guide you if any additional fixes or modifications are necessary. When reviewed and accepted, your pull request will be merged into our GitHub repository.
| `-G <generator>` | Specify project generator | For more information, run cmake `–help`. |
| `-DCMAKE_BUILD_TYPE=Debug` | Specify for Debug build | Not applicable for multi-configuration generators such as Visual Studio generator. |
| `-DTBB_VERIFY_DEPENDENCY_SIGNATURE=ON\|OFF` | Controls signature verification of dynamic dependencies loaded during runtime | If set to ON, only the signed dynamic dependencies are loaded. This is the recommended behavior. By default, the value is unspecified. Therefore, the warning is printed. To suppress the warning, set the value explicitly. |
For a more detailed list of available CMake configuration options see [Build System
Description](./cmake/README.md)
### Build oneTBB
To build the system, run:
```
cmake --build . <options>
```
Some useful build options:
-`--target <target>` - specific target, "all" is default.
-`--config <Release|Debug>` - build configuration, applicable only for multi-config generators such as Visual Studio generator.
### Install and Pack oneTBB
---
**NOTE**
Be careful about installing prefix. It defaults to `/usr/local` on UNIX* and `c:/Program Files/${PROJECT_NAME}` on Windows* OS.
You can define custom `CMAKE_INSTALL_PREFIX` during configuration:
The oneTBB port in vcpkg is kept up to date by Microsoft* team members and community contributors. If the version is out of date, create an issue or pull request on the [vcpkg repository](https://github.com/Microsoft/vcpkg).
### Example
#### Single-Configuration Generators
The following example demonstrates how to install oneTBB for single-configuration generators (e.g. GNU Make, Ninja, etc.).
| Ensure [Contribution Guidelines](./CONTRIBUTING.md) are followed | ✗ | ✓ | ✓ |
| Co-own component or aspect of the library,<br> including contributing: bug fixes, implementing features,<br> and performance optimizations | ✗ | ✓ | ✓ |
| Co-own on technical direction of component or<br> aspect of the library including work on RFCs | ✗ | ✓ | ✓ |
| Co-own the project as a whole,<br> including determining strategy and policy for the project | ✗ | ✗ | ✓ |
[](LICENSE.txt) [](https://github.com/uxlfoundation/oneTBB/actions/workflows/ci.yml?query=branch%3Amaster)
[](https://github.com/uxlfoundation/oneTBB/discussions)
[](https://www.bestpractices.dev/projects/9125)
oneAPI Threading Building Blocks (oneTBB) lets you easily write parallel C++ programs that take
full advantage of multicore performance, that are portable, composable and have future-proof scalability.
oneTBB is a flexible C++ library that simplifies the work of adding parallelism
to complex applications, even if you are not a threading expert.
The library lets you easily write parallel programs that take full advantage of the multi-core performance. Such programs are portable,
composable and have a future-proof scalability. oneTBB provides you with functions, interfaces, and classes to parallelize and scale the code.
All you have to do is to use the templates.
The library differs from typical threading packages in the following ways:
* oneTBB enables you to specify logical parallelism instead of threads.
* oneTBB targets threading for performance.
* oneTBB is compatible with other threading packages.
* oneTBB emphasizes scalable, data parallel programming.
* oneTBB relies on generic programming.
Refer to oneTBB [examples](examples) and [samples](https://github.com/oneapi-src/oneAPI-samples/tree/master/Libraries/oneTBB) to see how you can use the library.
oneTBB is a part of the [UXL Foundation](http://www.uxlfoundation.org) and is an implementation of [oneAPI specification](https://oneapi.io).
> **_NOTE:_** Threading Building Blocks (TBB) is now called oneAPI Threading Building Blocks (oneTBB) to highlight that the tool is a part of the oneAPI ecosystem.
## Release Information
Here are [Release Notes]( https://software.intel.com/en-us/articles/intel-oneapi-threading-building-blocks-release-notes) and
* [oneTBB Developer Guide and Reference](https://software.intel.com/en-us/oneapi-tbb-documentation)
* [Migrating from TBB to oneTBB](https://software.intel.com/content/www/us/en/develop/documentation/onetbb-documentation/top/onetbb-developer-guide/migrating-from-threading-building-blocks-tbb.html)
* README for build system: [cmake/README.md](cmake/README.md)
See [Installation from Sources](INSTALL.md) to learn how to install oneTBB.
## Governance
The oneTBB project is governed by the UXL Foundation.
You can get involved in this project in following ways:
* Join the [Open Source and Specification Working Group](https://github.com/uxlfoundation/foundation/tree/main?tab=readme-ov-file#working-groups) meetings.
* Join the mailing lists for the [UXL Foundation](https://lists.uxlfoundation.org/g/main/subgroups) to receive meetings schedule and latest updates.
* Contribute to oneTBB project or oneTBB specification. Read [CONTRIBUTING](./CONTRIBUTING.md) for more information.
## Support
Please report issues and suggestions via
[GitHub issues](https://github.com/oneapi-src/oneTBB/issues) or start a topic on the
Please use the sign-off line at the end of the patch.
Your signature certifies that you wrote the patch or
otherwise have the right to pass it on as an open-source patch.
The rules are pretty simple:
if you can certify the https://developercertificate.org then you just add a line to every git commit message:
```
Signed-off-by: Name Surname <user@email.com>
```
Use your real name (sorry, no pseudonyms or anonymous contributions).
If you set your `user.name` and `user.email` git configs, you can sign your
commit automatically with `git commit -s`.
Use GitHub Issues for feature requests, bug reports, and minor inquiries. For broader questions and development-related discussions, use GitHub Discussions.
## License
oneAPI Threading Building Blocks is licensed under [Apache License, Version 2.0](LICENSE.txt).
By its terms, contributions submitted to the project are also done under that license.
## Security
To report security issues please go to https://intel.com/security.
- NUMA Optimization: Use new interleaved memory allocation APIs to explicitly control memory placement across NUMA nodes. The ``allocate_numa_interleaved`` and ``deallocate_numa_interleaved`` functions allocate and deallocate memory across multiple NUMA nodes, helping increase bandwidth and avoid bottlenecks from single-node allocation.
- C++20 Modules: This release adds experimental support for C++20 modules with the introduction of ``include/oneapi/tbb.cppm``. Developers can use this instead of traditional headers to reduce compilation times and improve encapsulation.
## :tada: New Features
- oneTBB repository now contains Thread Composability Manager (TCM) source code - a project that helps in limiting oversubscription that can arise when multiple parallel runtimes are used within an application. More information is available at https://uxlfoundation.github.io/oneTBB/main/tbb_userguide/appendix_B.html#avoid-cpu-overutilization
## :rotating_light: Known Limitations
- The ``oneapi::tbb::info`` namespace interfaces might unexpectedly change the process affinity mask on Windows* OS systems (see https://github.com/open-mpi/hwloc/issues/366 for details) when using hwloc version lower than 2.5.
- Using a hwloc version other than 1.11, 2.0, or 2.5 may cause an undefined behavior on Windows OS. See https://github.com/open-mpi/hwloc/issues/477 for details.
- The NUMA topology may be detected incorrectly on Windows* OS machines where the number of NUMA node threads exceeds the size of 1 processor group.
- On Windows OS on ARM64*, when compiling an application using oneTBB with the Microsoft* Compiler, the compiler issues a warning C4324 that a structure was padded due to the alignment specifier. Consider suppressing the warning by specifying /wd4324 to the compiler command line.
- When CPU resource coordination is enabled by setting the TCM_ENABLE environment variable to 1, tasks from a lower-priority ``task_arena`` might be executed before tasks from a higher-priority ``task_arena``.
- Using oneTBB on WASM* may cause applications to run in a single thread. See [Limitations of WASM Support](https://github.com/uxlfoundation/oneTBB/blob/master/WASM_Support.md#limitations).
> **_NOTE:_** To see known limitations that impact all versions of oneTBB, refer to [oneTBB Documentation](https://uxlfoundation.github.io/oneTBB/main/intro/limitations.html).
## :hammer: Issues Fixed
- Added IPO build support for modern Intel compilers with old CMake under Linux*.
## :octocat: Open-Source Contributions Integrated
- Improved support for GNU* Hurd*. Contributed by Petter Reinholdtsen (https://github.com/uxlfoundation/oneTBB/pull/2028, https://github.com/uxlfoundation/oneTBB/pull/2038, https://github.com/uxlfoundation/oneTBB/pull/2026).
- Fixed Windows* build on ARM64* when using MSVC. contributed by navvyswethgraphics (https://github.com/uxlfoundation/oneTBB/pull/2030).
# oneTBB 2023.0 Release Notes
## :rocket: Preview Features
- Introduced ability to wait for a single task in a ``task_group`` instead of waiting for all tasks to finish. This increases reactivity and decreases latency in key user workloads.
- Introduced ``flow::resource_limited_node`` and ``flow::resource_limiter`` classes. These nodes only execute when they can successfully acquire the necessary resources from the resource limiters associated with the node. This feature is used to guard access to shared resources, while maximizing available parallelism in the graph.
- Introduced ``task_arena`` core type selector to better support hybrid architectures with several core types. Users use this new flexible API to more tightly constrain execution to set preferences for the specific core types that match their workload.
- Added global control parameter to set default block time behavior on server HW. This allows developers to revert to older blocking behavior if their applications are not able to fully utilize all cores, thereby reducing idle spinning.
## :tada: New Features
- Added new API to create a set of NUMA bound task arenas, simplifying common patterns used to optimize for NUMA architectures.
- Extended Flow Graph functional node deduction guides to support non-static member function and member object pointers as a node bodies.
- The Flow Graph join_node and indexer_node now support 10 or more input ports.
- Explicit deduction guides for ``blocked_nd_range`` are now a fully supported feature.
- Added native WASM exception handling support.
- Added support for Python 3.14.
## :rotating_light: Known Limitations
- The ``oneapi::tbb::info`` namespace interfaces might unexpectedly change the process affinity mask on Windows* OS systems (see https://github.com/open-mpi/hwloc/issues/366 for details) when using hwloc version lower than 2.5.
- Using a hwloc version other than 1.11, 2.0, or 2.5 may cause an undefined behavior on Windows OS. See https://github.com/open-mpi/hwloc/issues/477 for details.
- The NUMA topology may be detected incorrectly on Windows* OS machines where the number of NUMA node threads exceeds the size of 1 processor group.
- On Windows OS on ARM64*, when compiling an application using oneTBB with the Microsoft* Compiler, the compiler issues a warning C4324 that a structure was padded due to the alignment specifier. Consider suppressing the warning by specifying /wd4324 to the compiler command line.
- When CPU resource coordination is enabled by setting the TCM_ENABLE environment variable to 1, tasks from a lower-priority ``task_arena`` might be executed before tasks from a higher-priority ``task_arena``.
- Using oneTBB on WASM* may cause applications to run in a single thread. See [Limitations of WASM Support](https://github.com/uxlfoundation/oneTBB/blob/master/WASM_Support.md#limitations).
> **_NOTE:_** To see known limitations that impact all versions of oneTBB, refer to [oneTBB Documentation](https://uxlfoundation.github.io/oneTBB/main/intro/limitations.html).
## :hammer: Issues Fixed
- Significantly improved scalability for concurrent ordered containers on systems with many threads. This change results in greater than 3x performance for some use cases.
- Fixed ODR violations when public inline functions expose entities with internal linkage.
## :octocat: Open-Source Contributions Integrated
- Updated tbb4py installation approach to be aligned with PEP517. Contributed by Ben Greiner (https://github.com/uxlfoundation/oneTBB/pull/1941).
- Improved usage of <windows.h> in oneTBB code. Contributed by Aras Pranckevičius (https://github.com/uxlfoundation/oneTBB/pull/1932).
- Fixed CMake build issue with Clang on Windows*. Contributed by JustinZhu (https://github.com/uxlfoundation/oneTBB/pull/1936).
# oneTBB 2022.3 Release Notes
## :rocket: Preview Features
- Introduced API for setting dynamic task dependencies in task_group. This allows successor tasks to execute only after all their predecessors have completed.
## :tada: New Features
- Extended task_arena with API support for enqueuing functions into a task_group and waiting for the task_group to complete.
- Introduced API for setting and getting the assertion handler. This allows applications to set their own assertion handling functions.
## :rotating_light: Known Limitations
- The ``oneapi::tbb::info`` namespace interfaces might unexpectedly change the process affinity mask on Windows* OS systems (see https://github.com/open-mpi/hwloc/issues/366 for details) when using hwloc version lower than 2.5.
- Using a hwloc version other than 1.11, 2.0, or 2.5 may cause an undefined behavior on Windows OS. See https://github.com/open-mpi/hwloc/issues/477 for details.
- The NUMA topology may be detected incorrectly on Windows* OS machines where the number of NUMA node threads exceeds the size of 1 processor group.
- On Windows OS on ARM64*, when compiling an application using oneTBB with the Microsoft* Compiler, the compiler issues a warning C4324 that a structure was padded due to the alignment specifier. Consider suppressing the warning by specifying /wd4324 to the compiler command line.
- C++ exception handling mechanism on Windows* OS on ARM64* might corrupt memory if an exception is thrown from any oneTBB parallel algorithm (see Windows* OS on ARM64* compiler issue: https://developercommunity.visualstudio.com/t/ARM64-incorrect-stack-unwinding-for-alig/1544293.
- When CPU resource coordination is enabled by setting the TCM_ENABLE environment variable to 1, tasks from a lower-priority ``task_arena`` might be executed before tasks from a higher-priority ``task_arena``.
- When CPU resource coordination is enabled, cgroups CPU quota and period limitations settings are ignored.
- Using oneTBB on WASM* may cause applications to run in a single thread. See [Limitations of WASM Support](https://github.com/uxlfoundation/oneTBB/blob/master/WASM_Support.md#limitations).
> **_NOTE:_** To see known limitations that impact all versions of oneTBB, refer to [oneTBB Documentation](https://uxlfoundation.github.io/oneTBB/main/intro/limitations.html).
## :hammer: Issues Fixed
- Fixed overwrite_node and write_once_node to prevent premature trigger of continue_node successors.
- Fixed keys duplication in concurrent_hash_map when the container is initialized using a pair of iterators, or std::initializer_list (https://github.com/uxlfoundation/oneTBB/issues/1764).
- Improved support for profiling tools by allowing the oneTBB notifications to be ignored by tools and by better timing of task completion notifications.
- Fixed incorrect deallocation of tasks in task_group (https://github.com/uxlfoundation/oneTBB/issues/1834).
- Improved performance scalability of spin_mutex::lock, spin_mutex::try_lock and queuing_mutex::scoped_lock::try_acquire.
- Fixed potential oversubscription issue by respecting CPU quota and period limitations provided via cgroups settings on Linux* (https://github.com/uxlfoundation/oneTBB/issues/190, https://github.com/uxlfoundation/oneTBB/issues/1760).
## :octocat: Open-Source Contributions Integrated
- Fixed CMake build issue on some architectures. Contributed by lmarz (https://github.com/uxlfoundation/oneTBB/pull/1768).
- Fixed stack size assertion failure when running with ASAN. Contributed by omegacoleman (https://github.com/uxlfoundation/oneTBB/pull/1782).
- Improved Bazel support on non-x86 architectures. Contributed by Caleb Zulawski (https://github.com/uxlfoundation/oneTBB/pull/1790).
- Fixed potential crash caused by nullptr dereference for the tag_matching join_node. Contributed by Federico Ficarelli (https://github.com/uxlfoundation/oneTBB/pull/1800).
- Fixed ASAN detection for Clang*. Contributed by Federico Ficarelli (https://github.com/uxlfoundation/oneTBB/pull/1842).
# oneTBB 2022.2 Release Notes
## :tada: New Features
- Improved Hybrid CPU and NUMA Platforms API Support: Enhanced API availability for better compatibility with Hybrid CPU and NUMA platforms.
- Added support for verifying signatures of dynamic dependencies at runtime. To enable this feature, specify
``-DTBB_VERIFY_DEPENDENCY_SIGNATURE=ON`` when invoking CMake.
- Added support for printing warning messages about issues in dynamic dependency loading. To see these messages in the console, build the library with the ``TBB_DYNAMIC_LINK_WARNING`` macro defined.
- Added a Natvis file for custom visualization of TBB containers when debugging with Microsoft* Visual Studio.
- Refined Environment Setup: Replaced CPATH with ``C_INCLUDE_PATH and CPLUS_INCLUDE_PATH`` in environment setup to avoid unintended compiler warnings caused by globally applied include paths.
## :rotating_light: Known Limitations
- The ``oneapi::tbb::info`` namespace interfaces might unexpectedly change the process affinity mask on Windows* OS systems (see https://github.com/open-mpi/hwloc/issues/366 for details) when using hwloc version lower than 2.5.
- Using a hwloc version other than 1.11, 2.0, or 2.5 may cause an undefined behavior on Windows OS. See https://github.com/open-mpi/hwloc/issues/477 for details.
- The NUMA topology may be detected incorrectly on Windows* OS machines where the number of NUMA node threads exceeds the size of 1 processor group.
- On Windows OS on ARM64*, when compiling an application using oneTBB with the Microsoft* Compiler, the compiler issues a warning C4324 that a structure was padded due to the alignment specifier. Consider suppressing the warning by specifying /wd4324 to the compiler command line.
- C++ exception handling mechanism on Windows* OS on ARM64* might corrupt memory if an exception is thrown from any oneTBB parallel algorithm (see Windows* OS on ARM64* compiler issue: https://developercommunity.visualstudio.com/t/ARM64-incorrect-stack-unwinding-for-alig/1544293.
- When CPU resource coordination is enabled, tasks from a lower-priority ``task_arena`` might be executed before tasks from a higher-priority ``task_arena``.
- Using oneTBB on WASM* may cause applications to run in a single thread. See [Limitations of WASM Support](https://github.com/uxlfoundation/oneTBB/blob/master/WASM_Support.md#limitations).
> **_NOTE:_** To see known limitations that impact all versions of oneTBB, refer to [oneTBB Documentation](https://uxlfoundation.github.io/oneTBB/main/intro/limitations.html).
## :octocat: Open-Source Contributions Integrated
- Fixed a CMake configuration error on systems with non-English locales. Contributed by moritz-h (https://github.com/uxlfoundation/oneTBB/pull/1606).
- Made the install destination of import libraries on Windows* configurable. Contributed by Bora Yalçıner (https://github.com/uxlfoundation/oneTBB/pull/1613).
- Resolved an in-source CMake build error. Contributed by Dmitrii Golovanov (https://github.com/uxlfoundation/oneTBB/pull/1670).
- Migrated the build system to Bazel* version 8.1.1. Contributed by Julian Amann (https://github.com/uxlfoundation/oneTBB/pull/1694).
- Fixed build errors on MinGW* and FreeBSD*. Contributed by John Ericson (https://github.com/uxlfoundation/oneTBB/pull/1696).
- Addressed build errors on macOS* when using the GCC compiler. Contributed by Oleg Butakov (https://github.com/uxlfoundation/oneTBB/pull/1603).
# oneTBB 2022.1 Release Notes
## :tada: New Features
- The oneTBB repository migrated to the new [UXL Foundation](https://github.com/uxlfoundation/oneTBB) organization.
- ``blocked_nd_range`` is now a fully supported feature.
- Introduced the ``ONETBB_SPEC_VERSION`` macro to specify the version of oneAPI specification implemented by the current version of the library.
## :rocket: Preview Features
- Added the explicit deduction guides to ``blocked_nd_range`` to support C++17 Class Template Argument Deduction.
- Extended ``task_arena`` API to select TBB workers leave policy and to hint the start and the end of parallel computations.
## :rotating_light: Known Limitations
- The ``oneapi::tbb::info`` namespace interfaces might unexpectedly change the process affinity mask on Windows* OS systems (see https://github.com/open-mpi/hwloc/issues/366 for details) when using hwloc version lower than 2.5.
- Using a hwloc version other than 1.11, 2.0, or 2.5 may cause an undefined behavior on Windows OS. See https://github.com/open-mpi/hwloc/issues/477 for details.
- The NUMA topology may be detected incorrectly on Windows* OS machines where the number of NUMA node threads exceeds the size of 1 processor group.
- On Windows OS on ARM64*, when compiling an application using oneTBB with the Microsoft* Compiler, the compiler issues a warning C4324 that a structure was padded due to the alignment specifier. Consider suppressing the warning by specifying /wd4324 to the compiler command line.
- C++ exception handling mechanism on Windows* OS on ARM64* might corrupt memory if an exception is thrown from any oneTBB parallel algorithm (see Windows* OS on ARM64* compiler issue: https://developercommunity.visualstudio.com/t/ARM64-incorrect-stack-unwinding-for-alig/1544293.
- When CPU resource coordination is enabled, tasks from a lower-priority ``task_arena`` might be executed before tasks from a higher-priority ``task_arena``.
- Using oneTBB on WASM* may cause applications to run in a single thread. See [Limitations of WASM Support](https://github.com/uxlfoundation/oneTBB/blob/master/WASM_Support.md#limitations).
> **_NOTE:_** To see known limitations that impact all versions of oneTBB, refer to [oneTBB Documentation](https://uxlfoundation.github.io/oneTBB/main/intro/limitations.html).
## :hammer: Issues Fixed
- Fixed deadlock when using `tbb::concurrent_vector::grow_by()` (https://github.com/uxlfoundation/oneTBB/issues/1531).
- Fixed assertion in the Debug version of oneTBB on systems with multiple processor groups.
- Fixed issues with Flow Graph priorities when using limited concurrency nodes (https://github.com/uxlfoundation/oneTBB/issues/1595).
- Improved support of ``tbb::task_arena::constraints`` functionality on Windows* systems with multiple processor groups.
- Fixed ``concurrent_queue`` and ``concurrent_bounded_queue`` capacity preserving on copying, moving, and swapping (https://github.com/uxlfoundation/oneTBB/issues/1598).
- Fixed ``parallel_for_each`` compilation issues on GCC 9 in C++20 mode (https://github.com/uxlfoundation/oneTBB/issues/1552).
## :octocat: Open-Source Contributions Integrated
- Fixed linkage errors when the application is built with the hidden symbols visibility. Contributed by Vladislav Shchapov (https://github.com/uxlfoundation/oneTBB/pull/1114).
- On Linux* OS, for external thread, determined stack size using POSIX* API instead of relying on the stack size of a worker thread. Contributed by bongkyu7-kim (https://github.com/uxlfoundation/oneTBB/pull/1485).
- Added a CMake option to use relative paths instead of full paths in debug information. Contributed by Fang Xu (https://github.com/uxlfoundation/oneTBB/pull/1401).
- Improved OpenBSD* support by removing the use of direct syscalls. Contributed by Brad Smith (https://github.com/uxlfoundation/oneTBB/pull/1499).
- Fixed build issues on ARM64* when using Bazel. Contributed by snadampal (https://github.com/uxlfoundation/oneTBB/pull/1571).
- Suppressed deprecation warnings for CMake versions earlier than 3.10 when using the latest CMake. Contributed by Vladislav Shchapov (https://github.com/uxlfoundation/oneTBB/pull/1585).
# oneTBB 2022.0 Release Notes
## :rocket: Preview Features
- Extended the Flow Graph receiving nodes with a new ``try_put_and_wait`` API that submits a message to the graph and waits for its completion.
## :rotating_light: Known Limitations
- The ``oneapi::tbb::info`` namespace interfaces might unexpectedly change the process affinity mask on Windows* OS systems (see https://github.com/open-mpi/hwloc/issues/366 for details) when using hwloc version lower than 2.5.
- Using a hwloc version other than 1.11, 2.0, or 2.5 may cause an undefined behavior on Windows OS. See https://github.com/open-mpi/hwloc/issues/477 for details.
- The NUMA topology may be detected incorrectly on Windows* OS machines where the number of NUMA node threads exceeds the size of 1 processor group.
- On Windows OS on ARM64*, when compiling an application using oneTBB with the Microsoft* Compiler, the compiler issues a warning C4324 that a structure was padded due to the alignment specifier. Consider suppressing the warning by specifying /wd4324 to the compiler command line.
- C++ exception handling mechanism on Windows* OS on ARM64* might corrupt memory if an exception is thrown from any oneTBB parallel algorithm (see Windows* OS on ARM64* compiler issue: https://developercommunity.visualstudio.com/t/ARM64-incorrect-stack-unwinding-for-alig/1544293.
- When CPU resource coordination is enabled, tasks from a lower-priority ``task_arena`` might be executed before tasks from a higher-priority ``task_arena``.
- Using oneTBB on WASM*, may cause applications to run in a single thread. See [Limitations of WASM Support](https://github.com/oneapi-src/oneTBB/blob/master/WASM_Support.md#limitations).
> **_NOTE:_** To see known limitations that impact all versions of oneTBB, refer to [oneTBB Documentation](https://oneapi-src.github.io/oneTBB/main/intro/limitations.html).
## :hammer: Issues Fixed
- Fixed the missed signal for thread request for enqueue operation.
- Significantly improved scalability of ``task_group``, ``flow_graph``, and ``parallel_for_each``.
- Removed usage of ``std::aligned_storage`` deprecated in C++23 (Inspired by Valery Matskevich https://github.com/oneapi-src/oneTBB/pull/1394).
- Fixed the issue where ``oneapi::tbb::info`` interfaces might interfere with the process affinity mask on the Windows* OS systems with multiple processor groups.
## :octocat: Open-Source Contributions Integrated
- Detect the GNU Binutils version to determine WAITPKG support better. Contributed by Martijn Courteaux (https://github.com/oneapi-src/oneTBB/pull/1347).
- Fixed the build on non-English locales. Contributed by Vladislav Shchapov (https://github.com/oneapi-src/oneTBB/pull/1450).
- Improved Bazel support. Contributed by Julian Amann (https://github.com/oneapi-src/oneTBB/pull/1434).
# oneTBB 2021.13 Release Notes
## :tada: New Features
- Extended the parallel_reduce and parallel_deterministic_reduce functional form API to better support rvalues reduction (https://github.com/uxlfoundation/oneTBB/pull/1299).
## :rotating_light: Known Limitations
- The ``oneapi::tbb::info`` namespace interfaces might unexpectedly change the process affinity mask on Windows* OS systems (see https://github.com/open-mpi/hwloc/issues/366 for details) when using hwloc version lower than 2.5.
- Using a hwloc version other than 1.11, 2.0, or 2.5 may cause an undefined behavior on Windows OS. See https://github.com/open-mpi/hwloc/issues/477 for details.
- The NUMA topology may be detected incorrectly on Windows* OS machines where the number of NUMA node threads exceeds the size of 1 processor group.
- On Windows OS on ARM64*, when compiling an application using oneTBB with the Microsoft* Compiler, the compiler issues a warning C4324 that a structure was padded due to the alignment specifier. Consider suppressing the warning by specifying /wd4324 to the compiler command line.
- C++ exception handling mechanism on Windows* OS on ARM64* might corrupt memory if an exception is thrown from any oneTBB parallel algorithm (see Windows* OS on ARM64* compiler issue: https://developercommunity.visualstudio.com/t/ARM64-incorrect-stack-unwinding-for-alig/1544293.
- When CPU resource coordination is enabled, tasks from a lower-priority ``task_arena`` might be executed before tasks from a higher-priority ``task_arena``.
- Using oneTBB on WASM* may cause applications to run in a single thread. See [Limitations of WASM Support](https://github.com/uxlfoundation/oneTBB/blob/master/WASM_Support.md#limitations).
> **_NOTE:_** To see known limitations that impact all versions of oneTBB, refer to [oneTBB Documentation](https://uxlfoundation.github.io/oneTBB/main/intro/limitations.html).
## :hammer: Issues Fixed
- Improved security by excluding CWD from search of load-time dependencies.
- Improved performance on Apple* platforms by aligning block-time behavior with other OS.
- Improved performance on non-hybrid CPU hardware by reworking block-time behavior.
- Improved performance on ARM64 platform by fixing backoff behavior for spin loops.
- Improved performance when constraints API is used on server CPU HW with multiple NUMA nodes.
## :octocat: Open-Source Contributions Integrated
- Improved WASM support by fixing a segmentation fault happening if global tbb::task_scheduler_observer is used. Contributed by Santiago Ospina De Los Ríos https://github.com/oneapi-src/oneTBB/pull#1346).
# oneTBB 2021.12 Release Notes
## :rotating_light: Known Limitations
- The ``oneapi::tbb::info`` namespace interfaces might unexpectedly change the process affinity mask on Windows* OS systems (see https://github.com/open-mpi/hwloc/issues/366 for details) when using hwloc version lower than 2.5.
- Using a hwloc version other than 1.11, 2.0, or 2.5 may cause an undefined behavior on Windows OS. See https://github.com/open-mpi/hwloc/issues/477 for details.
- The NUMA topology may be detected incorrectly on Windows* OS machines where the number of NUMA node threads exceeds the size of 1 processor group.
- On Windows OS on ARM64*, when compiling an application using oneTBB with the Microsoft* Compiler, the compiler issues a warning C4324 that a structure was padded due to the alignment specifier. Consider suppressing the warning by specifying /wd4324 to the compiler command line.
- C++ exception handling mechanism on Windows* OS on ARM64* might corrupt memory if an exception is thrown from any oneTBB parallel algorithm (see Windows* OS on ARM64* compiler issue: https://developercommunity.visualstudio.com/t/ARM64-incorrect-stack-unwinding-for-alig/1544293.
- When CPU resource coordination is enabled, tasks from a lower-priority ``task_arena`` might be executed before tasks from a higher-priority ``task_arena``.
> **_NOTE:_** To see known limitations that impact all versions of oneTBB, refer to [oneTBB Documentation](https://oneapi-src.github.io/oneTBB/main/intro/limitations.html).
## :hammer: Issues Fixed
- Fixed ``parallel_for_each`` algorithm behavior for iterators defining ``iterator_concept`` trait instead of ``iterator_category``.
- Fixed the redefinition issue for ``std::min`` and ``std::max`` on Windows* OS ([GitHub* #832](https://github.com/oneapi-src/oneTBB/issues/832)).
- Fixed the incorrect binary search order in ``TBBConfig.cmake``.
- Enabled the oneTBB library search using the pkg-config tool in Conda packages.
## :octocat: Open-Source Contributions Integrated
- Fixed the compiler warning for missing virtual destructor. Contributed by Elias Engelbert Plank (https://github.com/oneapi-src/oneTBB/pull/1215).
# oneTBB 2021.11 Release Notes
## :rotating_light: Known Limitations
- The ``oneapi::tbb::info`` namespace interfaces might unexpectedly change the process affinity mask on Windows* OS systems (see https://github.com/open-mpi/hwloc/issues/366 for details) when using hwloc version lower than 2.5.
- Using a hwloc version other than 1.11, 2.0, or 2.5 may cause an undefined behavior on Windows OS. See https://github.com/open-mpi/hwloc/issues/477 for details.
- The NUMA topology may be detected incorrectly on Windows* OS machines where the number of NUMA node threads exceeds the size of 1 processor group.
- On Windows OS on ARM64*, when compiling an application using oneTBB with the Microsoft* Compiler, the compiler issues a warning C4324 that a structure was padded due to the alignment specifier. Consider suppressing the warning by specifying /wd4324 to the compiler command line.
- C++ exception handling mechanism on Windows* OS on ARM64* might corrupt memory if an exception is thrown from any oneTBB parallel algorithm (see Windows* OS on ARM64* compiler issue: https://developercommunity.visualstudio.com/t/ARM64-incorrect-stack-unwinding-for-alig/1544293).
- Using ``TBBConfig.cmake`` in 32-bit environment may cause incorrect linkage with 64-bit oneTBB library. As a workaround, set ``CMAKE_PREFIX_PATH``:
- On Linux* OS: to ``TBBROOT/lib32/``
- On Windows* OS: to ``TBBROOT/lib32/;TBBROOT/bin32/``
> **_NOTE:_** To see known limitations that impact all versions of oneTBB, refer to [oneTBB Documentation](https://oneapi-src.github.io/oneTBB/main/intro/limitations.html).
## :hammer: Issues Fixed
- Fixed ``tbb::this_task_arena()`` behavior for specific ``tbb::task_arena{1,0}``.
- Restored performance on systems with a high number of CPU cores that support ``_tpause``.
# oneTBB 2021.10 Release Notes
## :tada: New Features
- Since C++17, parallel algorithms and Flow Graph nodes are allowed to accept pointers to the member functions and member objects as the user-provided callables.
- Added missed member functions, such as assignment operators and swap function, to the ``concurrent_queue`` and ``concurrent_bounded_queue`` containers.
## :rotating_light: Known Limitations
- A static assert will cause compilation failures in oneTBB headers when compiling with clang 12.0.0 or newer if using the LLVM standard library with ``-ffreestanding`` and C++11/14 compiler options.
- An application using Parallel STL algorithms in libstdc++ versions 9 and 10 may fail to compile due to incompatible interface changes between earlier versions of Threading Building Blocks (TBB) and oneAPI Threading Building Blocks (oneTBB). Disable support for Parallel STL algorithms by defining ``PSTL_USE_PARALLEL_POLICIES`` (in libstdc++ 9) or ``_GLIBCXX_USE_TBB_PAR_BACKEND`` (in libstdc++ 10) macro to zero before inclusion of the first standard header file in each translation unit.
- On Linux* OS, if oneAPI Threading Building Blocks (oneTBB) or Threading Building Blocks (TBB) are installed in a system folder like ``/usr/lib64``, the application may fail to link due to the order in which the linker searches for libraries. Use the ``-L`` linker option to specify the correct location of oneTBB library. This issue does not affect the program execution.
- The ``oneapi::tbb::info`` namespace interfaces might unexpectedly change the process affinity mask on Windows* OS systems (see https://github.com/open-mpi/hwloc/issues/366 for details) when using hwloc* version lower than 2.5.
- Using a hwloc* version other than 1.11, 2.0, or 2.5 may cause an undefined behavior on Windows* OS. See https://github.com/open-mpi/hwloc/issues/477 for details.
- The NUMA* topology may be detected incorrectly on Windows* OS machines where the number of NUMA* node threads exceeds the size of 1 processor group.
- On Windows* OS on ARM64*, when compiling an application using oneTBB with the Microsoft* Compiler, the compiler issues a warning C4324 that a structure was padded due to the alignment specifier. Consider suppressing the warning by specifying ``/wd4324`` to the compiler command line.
- oneTBB does not support ``fork()``, to work-around the issue, consider using task_scheduler_handle to join oneTBB worker threads before using fork().
- C++ exception handling mechanism on Windows* OS on ARM64* might corrupt memory if an exception is thrown from any oneTBB parallel algorithm (see Windows* OS on ARM64* compiler issue: https://developercommunity.visualstudio.com/t/ARM64-incorrect-stack-unwinding-for-alig/1544293).
## :hammer: Issues Fixed
- Fixed the hang in the reserve method of concurrent unordered containers ([GitHub* #1056](http://github.com/oneapi-src/oneTBB/issues/1056)).
- Fixed the C++20 three-way comparison feature detection ([GitHub* #1093](http://github.com/oneapi-src/oneTBB/issues/1093)).
- Fixed oneTBB integration with CMake* in the Conda* environment.
# oneTBB 2021.9 Release Notes
## :tada: New Features
- Hybrid CPU support is now a fully supported feature.
## :rotating_light: Known Limitations
- A static assert will cause compilation failures in oneTBB headers when compiling with clang 12.0.0 or newer if using the LLVM standard library with -ffreestanding and C++11/14 compiler options.
- An application using Parallel STL algorithms in libstdc++ versions 9 and 10 may fail to compile due to incompatible interface changes between earlier versions of Threading Building Blocks (TBB) and oneAPI Threading Building Blocks (oneTBB). Disable support for Parallel STL algorithms by defining PSTL_USE_PARALLEL_POLICIES (in libstdc++ 9) or _GLIBCXX_USE_TBB_PAR_BACKEND (in libstdc++ 10) macro to zero before inclusion of the first standard header file in each translation unit.
- On Linux* OS, if oneAPI Threading Building Blocks (oneTBB) or Threading Building Blocks (TBB) are installed in a system folder like /usr/lib64, the application may fail to link due to the order in which the linker searches for libraries. Use the -L linker option to specify the correct location of oneTBB library. This issue does not affect the program execution.
- The oneapi::tbb::info namespace interfaces might unexpectedly change the process affinity mask on Windows* OS systems (see https://github.com/open-mpi/hwloc/issues/366 for details) when using hwloc version lower than 2.5.
- Using a hwloc version other than 1.11, 2.0, or 2.5 may cause an undefined behavior on Windows OS. See https://github.com/open-mpi/hwloc/issues/477 for details.
- The NUMA topology may be detected incorrectly on Windows OS machines where the number of NUMA node threads exceeds the size of 1 processor group.
- On Windows OS on ARM64*, when compiling an application using oneTBB with the Microsoft* Compiler, the compiler issues a warning C4324 that a structure was padded due to the alignment specifier. Consider suppressing the warning by specifying /wd4324 to the compiler command line.
- oneTBB does not support fork(), to work-around the issue, consider using task_scheduler_handle to join oneTBB worker threads before using fork().
- C++ exception handling mechanism on Windows* OS on ARM64* might corrupt memory if an exception is thrown from any oneTBB parallel algorithm (see Windows* OS on ARM64* compiler issue: https://developercommunity.visualstudio.com/t/ARM64-incorrect-stack-unwinding-for-alig/1544293).
## :hammer: Issues Fixed
- Improved robustness of thread creation algorithm on Linux* OS.
- Enabled full support of Thread Sanitizer on macOS*
- Fixed the issue with destructor calls for uninitialized objects in oneapi::tbb::parallel_for_each algorithm (GitHub* #691)
- Fixed the issue with tbb::concurrent_lru_cache when items history capacity is zero (GitHub* #265)
- Fixed compilation issues on modern GCC* versions
## :octocat: Open-Source Contributions Integrated
- Fixed the issue reported by the Address Sanitizer. Contributed by Rui Ueyama (https://github.com/oneapi-src/oneTBB/pull/959).
- Fixed the input_type alias exposed by flow_graph::join_node. Contributed by Deepan (https://github.com/oneapi-src/oneTBB/pull/868).
# oneTBB 2021.8 Release Notes
## :rotating_light: Known Limitations
- A static assert causes compilation failures in oneTBB headers when compiling with Clang* 12.0.0 or newer if using the LLVM* standard library with -ffreestanding and C++11/14 compiler options.
- An application using Parallel STL algorithms in libstdc++ versions 9 and 10 may fail to compile due to incompatible interface changes between earlier versions of Threading Building Blocks (TBB) and oneAPI Threading Building Blocks (oneTBB). Disable support for Parallel STL algorithms by defining PSTL_USE_PARALLEL_POLICIES (in libstdc++ 9) or _GLIBCXX_USE_TBB_PAR_BACKEND (in libstdc++ 10) macro to zero before inclusion of the first standard header file in each translation unit.
- On Linux* OS, if oneAPI Threading Building Blocks (oneTBB) or Threading Building Blocks (TBB) are installed in a system folder like /usr/lib64, the application may fail to link due to the order in which the linker searches for libraries. Use the -L linker option to specify the correct location of oneTBB library. This issue does not affect the program execution.
- The oneapi::tbb::info namespace interfaces might unexpectedly change the process affinity mask on Windows* OS systems (see https://github.com/open-mpi/hwloc/issues/366 for details) when using hwloc version lower than 2.5.
- Using a hwloc version other than 1.11, 2.0, or 2.5 may cause an undefined behavior on Windows* OS. See https://github.com/open-mpi/hwloc/issues/477 for details.
- The NUMA topology may be detected incorrectly on Windows OS machines where the number of NUMA node threads exceeds the size of 1 processor group.
- On Windows OS on ARM64*, when compiling an application using oneTBB with the Microsoft* Compiler, the compiler issues a warning C4324 that a structure was padded due to the alignment specifier. Consider suppressing the warning by specifying /wd4324 to the compiler command line.
- oneTBB does not support fork(), to work-around the issue, consider using task_scheduler_handle to join oneTBB worker threads before using fork().
- C++ exception handling mechanism on Windows* OS on ARM64* might corrupt memory if an exception is thrown from any oneTBB parallel algorithm (see Windows* OS on ARM64* compiler issue: https://developercommunity.visualstudio.com/t/ARM64-incorrect-stack-unwinding-for-alig/1544293).
## :hammer: Issues Fixed
- Fixed oneapi::tbb::concurrent_bounded_queue::pop return type (GitHub* [#807](https://github.com/oneapi-src/oneTBB/issues/807)).
- Fixed oneapi::tbb::concurrent_queue and oneapi::tbb::concurrent_bounded_queue with non-default constructible value types (GitHub* [#885](https://github.com/oneapi-src/oneTBB/issues/885)).
- Fixed incorrect splitting of iteration space in case there is no support for proportional splitting in custom ranges.
## :octocat: Open-Source Contributions Integrated
- Fix for full LTO* build, library and tests, on UNIX* OS systems. Contributed by Vladislav Shchapov (https://github.com/oneapi-src/oneTBB/pull/798).
# oneTBB 2021.7 Release Notes
## :rotating_light: Known Limitations
- A static assert causes compilation failures in oneTBB headers when compiling with Clang* 12.0.0 or newer if using the LLVM* standard library with -ffreestanding and C++11/14 compiler options.
- An application using Parallel STL algorithms in libstdc++ versions 9 and 10 may fail to compile due to incompatible interface changes between earlier versions of Threading Building Blocks (TBB) and oneAPI Threading Building Blocks (oneTBB). Disable support for Parallel STL algorithms by defining PSTL_USE_PARALLEL_POLICIES (in libstdc++ 9) or _GLIBCXX_USE_TBB_PAR_BACKEND (in libstdc++ 10) macro to zero before inclusion of the first standard header file in each translation unit.
- On Linux* OS, if oneAPI Threading Building Blocks (oneTBB) or Threading Building Blocks (TBB) are installed in a system folder like /usr/lib64, the application may fail to link due to the order in which the linker searches for libraries. Use the -L linker option to specify the correct location of oneTBB library. This issue does not affect the program execution.
- The oneapi::tbb::info namespace interfaces might unexpectedly change the process affinity mask on Windows* OS systems (see https://github.com/open-mpi/hwloc/issues/366 for details) when using hwloc version lower than 2.5.
- Using a hwloc version other than 1.11, 2.0, or 2.5 may cause an undefined behavior on Windows* OS. See https://github.com/open-mpi/hwloc/issues/477 for details.
- The NUMA topology may be detected incorrectly on Windows OS machines where the number of NUMA node threads exceeds the size of 1 processor group.
- On Windows OS on ARM64*, when compiling an application using oneTBB with the Microsoft* Compiler, the compiler issues a warning C4324 that a structure was padded due to the alignment specifier. Consider suppressing the warning by specifying /wd4324 to the compiler command line.
- oneTBB does not support fork(), to work-around the issue, consider using task_scheduler_handle to join oneTBB worker threads before using fork().
- C++ exception handling mechanism on Windows* OS on ARM64* might corrupt memory if an exception is thrown from any oneTBB parallel algorithm (see Windows* OS on ARM64* compiler issue: https://developercommunity.visualstudio.com/t/ARM64-incorrect-stack-unwinding-for-alig/1544293).
## :hammer: Issues Fixed
- Memory allocator crash when allocating ~1TB on 64-bit systems (GitHub* [#838](https://github.com/oneapi-src/oneTBB/issues/838)).
- Fixed thread distribution over NUMA nodes on Windows* OS systems.
- For oneapi::tbb::suspend, it is guaranteed that the user-specified callable object is executed by the calling thread.
## :octocat: Open-Source Contributions Integrated
- Fix for full LTO* build, library and tests, on UNIX* OS systems. Contributed by Vladislav Shchapov (https://github.com/oneapi-src/oneTBB/pull/798).
# oneTBB 2021.6 Release Notes
## :tada: New Features
- Improved support and use of the latest C++ standards for parallel_sort that allows using this algorithm with user-defined and standard library-defined objects with modern semantics.
- The following features are now fully functional: task_arena extensions, collaborative_call_once, adaptive mutexes, heterogeneous overloads for concurrent_hash_map, and task_scheduler_handle.
- Added support for Windows* Server 2022 and Python 3.10.
## :rotating_light: Known Limitations
- An application using Parallel STL algorithms in libstdc++ versions 9 and 10 may fail to compile due to incompatible interface changes between earlier versions of Threading Building Blocks (TBB) and oneAPI Threading Building Blocks (oneTBB). Disable support for Parallel STL algorithms by defining PSTL_USE_PARALLEL_POLICIES (in libstdc++ 9) or _GLIBCXX_USE_TBB_PAR_BACKEND (in libstdc++ 10) macro to zero before inclusion of the first standard header file in each translation unit.
- On Linux* OS, if oneAPI Threading Building Blocks (oneTBB) or Threading Building Blocks (TBB) are installed in a system folder like /usr/lib64, the application may fail to link due to the order in which the linker searches for libraries. Use the -L linker option to specify the correct location of oneTBB library. This issue does not affect the program execution.
- The oneapi::tbb::info namespace interfaces might unexpectedly change the process affinity mask on Windows* OS systems (see https://github.com/open-mpi/hwloc/issues/366 for details) when using hwloc version lower than 2.5.
- Using a hwloc version other than 1.11, 2.0, or 2.5 may cause an undefined behavior on Windows OS. See https://github.com/open-mpi/hwloc/issues/477 for details.
- The NUMA topology may be detected incorrectly on Windows OS machines where the number of NUMA node threads exceeds the size of 1 processor group.
- On Windows OS on ARM64*, when compiling an application using oneTBB with the Microsoft* Compiler, the compiler issues a warning C4324 that a structure was padded due to the alignment specifier. Consider suppressing the warning by specifying /wd4324 to the compiler command line.
- oneTBB does not support fork(), to work-around the issue, consider using task_scheduler_handle to join oneTBB worker threads before using fork().
- C++ exception handling mechanism on Windows* OS on ARM64* might corrupt memory if an exception is thrown from any oneTBB parallel algorithm (see Windows* OS on ARM64* compiler issue: https://developercommunity.visualstudio.com/t/ARM64-incorrect-stack-unwinding-for-alig/1544293).
## :hammer: Issues Fixed
- Memory allocator crash on a system with an incomplete /proc/meminfo (GitHub* [#584](https://github.com/oneapi-src/oneTBB/issues/584)).
- Incorrect blocking of task stealing (GitHub* #[478](https://github.com/oneapi-src/oneTBB/issues/478)).
- Hang due to incorrect decrement of a limiter_node (GitHub* [#634](https://github.com/oneapi-src/oneTBB/issues/634)).
- Memory corruption in some rare cases when passing big messages in a flow graph (GitHub* [#639](https://github.com/oneapi-src/oneTBB/issues/639)).
- Possible deadlock in a throwable flow graph node with a lightweight policy. The lightweight policy is now ignored for functors that can throw exceptions (GitHub* [#420](https://github.com/oneapi-src/oneTBB/issues/420)).
- Crash when obtaining a range from empty ordered and unordered containers (GitHub* [#641](https://github.com/oneapi-src/oneTBB/issues/641)).
- Deadlock in a concurrent_vector resize() that could happen when the new size is less than the previous size (GitHub* [#733](https://github.com/oneapi-src/oneTBB/issues/733)).
## :octocat: Open-Source Contributions Integrated
- Improved aligned memory allocation. Contributed by Andrey Semashev (https://github.com/oneapi-src/oneTBB/pull/671).
- Optimized usage of atomic_fence on IA-32 and Intel(R) 64 architectures. Contributed by Andrey Semashev (https://github.com/oneapi-src/oneTBB/pull/328).
- Fixed incorrect definition of the assignment operator in containers. Contributed by Andrey Semashev (https://github.com/oneapi-src/oneTBB/issues/372).
# oneTBB 2021.5 Release Notes
## :rocket: Preview Features
- Extended task_group interface with a new run_and_wait overload to accept task_handle.
## :tada: New Features
- Enabled Microsoft Visual Studio* 2022 and Python 3.9 support.
## :rotating_light: Known Limitations
- An application using Parallel STL algorithms in libstdc++ versions 9 and 10 may fail to compile due to incompatible interface changes between earlier versions of Threading Building Blocks (TBB) and oneAPI Threading Building Blocks (oneTBB). Disable support for Parallel STL algorithms by defining PSTL_USE_PARALLEL_POLICIES (in libstdc++ 9) or _GLIBCXX_USE_TBB_PAR_BACKEND (in libstdc++ 10) macro to zero before inclusion of the first standard header file in each translation unit.
- On Linux* OS, if oneAPI Threading Building Blocks (oneTBB) or Threading Building Blocks (TBB) are installed in a system folder like /usr/lib64, the application may fail to link due to the order in which the linker searches for libraries. Use the -L linker option to specify the correct location of oneTBB library. This issue does not affect the program execution.
- The oneapi::tbb::info namespace interfaces might unexpectedly change the process affinity mask on Windows* OS systems (see https://github.com/open-mpi/hwloc/issues/366 for details) when using hwloc version lower than 2.5.
- Using a hwloc version other than 1.11, 2.0, or 2.5 may cause an undefined behavior on Windows OS. See https://github.com/open-mpi/hwloc/issues/477 for details.
- The NUMA topology may be detected incorrectly on Windows OS machines where the number of NUMA node threads exceeds the size of 1 processor group.
- On Windows OS on ARM64*, when compiling an application using oneTBB with the Microsoft* Compiler, the compiler issues a warning C4324 that a structure was padded due to the alignment specifier. Consider suppressing the warning by specifying /wd4324 to the compiler command line.
- oneTBB does not support fork(), to work-around the issue, consider using task_scheduler_handle to join oneTBB worker threads before using fork().
- C++ exception handling mechanism on Windows* OS on ARM64* might corrupt memory if an exception is thrown from any oneTBB parallel algorithm (see Windows* OS on ARM64* compiler issue: https://developercommunity.visualstudio.com/t/ARM64-incorrect-stack-unwinding-for-alig/1544293).
## :hammer: Issues Fixed
- Reworked synchronization mechanism to reduce contention when multiple task_arena's are used concurrently.
- Fixed possible correctness issue in queuing_rw_mutex on non-Intel platforms.
- Fixed GCC* 11 warnings.
- Fixed sporadic memory corruption.
# oneTBB 2021.4 Release Notes
## :rocket: Preview Features
- Introduced the collaborative_call_once algorithm that executes the callable object exactly once, but allows other threads to join oneTBB parallel construction used inside this callable object. Inspired by Ben FrantzDale and Henry Heffan.
## :rotating_light: Known Limitations
- An application using Parallel STL algorithms in libstdc++ versions 9 and 10 may fail to compile due to incompatible interface changes between earlier versions of Threading Building Blocks (TBB) and oneAPI Threading Building Blocks (oneTBB). Disable support for Parallel STL algorithms by defining PSTL_USE_PARALLEL_POLICIES (in libstdc++ 9) or _GLIBCXX_USE_TBB_PAR_BACKEND (in libstdc++ 10) macro to zero before inclusion of the first standard header file in each translation unit.
- On Linux* OS, if oneAPI Threading Building Blocks (oneTBB) or Threading Building Blocks (TBB) are installed in a system folder like /usr/lib64, the application may fail to link due to the order in which the linker searches for libraries. Use the -L linker option to specify the correct location of oneTBB library. This issue does not affect the program execution.
- The oneapi::tbb::info namespace interfaces might unexpectedly change the process affinity mask on Windows* OS systems (see https://github.com/open-mpi/hwloc/issues/366 for details) when using hwloc version lower than 2.5.
- Using a hwloc version other than 1.11, 2.0, or 2.5 may cause an undefined behavior on Windows OS. See https://github.com/open-mpi/hwloc/issues/477 for details.
- The NUMA topology may be detected incorrectly on Windows OS machines where the number of NUMA node threads exceeds the size of 1 processor group.
- On Windows OS on ARM64*, when compiling an application using oneTBB with the Microsoft* Compiler, the compiler issues a warning C4324 that a structure was padded due to the alignment specifier. Consider suppressing the warning by specifying /wd4324 to the compiler command line.
- oneTBB does not support fork(), to work-around the issue, consider using task_scheduler_handle to join oneTBB worker threads before using fork().
## :hammer: Issues Fixed
- Enabled full support of Address Sanitizer and Thread Sanitizer.
- Fixed a race condition in tbbmalloc that may cause a crash in realloc() when using tbbmalloc_proxy.
- Enabled GCC* 11 support.
- Fixed limiter_node behavior when an integral type is used as an argument for the DecrementType template parameter.
- Fixed a possible memory leak when the static or affinity partitioners are used.
- Fixed possible system oversubscription when using a process mask and an explicit number of threads in the task arena.
## :octocat: Open-Source Contributions Integrated
- Enabled PowerPC* Linux* OS support. Contributed by Mircho Rodozov (https://github.com/oneapi-src/oneTBB/pull/461)
- Improved UNIX* system support and enabled QNX Neutrino* RTOS support. Contributed by Pablo Romero (https://github.com/oneapi-src/oneTBB/pull/440)
- Enabled experimental Bazel* build system support. Contributed by Julian Amann (https://github.com/oneapi-src/oneTBB/pull/442)
- Enabled oneTBB build for Windows* OS on ARM64*. Contributed by Michael Vitrano (https://github.com/oneapi-src/oneTBB/pull/507)
- Added MinGW* and export attributes support. Contributed by Long Nguyen (https://github.com/oneapi-src/oneTBB/pull/351)
We are committed to providing support and assistance to help you make the most out of oneTBB.
Use the following methods if you face any challenges.
## Issues
If you have a problem, check out the [GitHub Issues](https://github.com/uxlfoundation/oneTBB/issues) to see if the issue you want to address is already reported.
You may find users that have encountered the same bug or have similar ideas for changes or updates.
You can use issues to report a problem, make a feature request, or add comments on an existing issue.
## Discussions
Visit the [GitHub Discussions](https://github.com/uxlfoundation/oneTBB/discussions) to engage with the community, ask questions, or help others.
## Email
Reach out to us privately via [email](mailto:inteltbbdevelopers@intel.com).
- Non-Intel(R) processors compatible with the processors listed above
Changes to the list of supported hardware will be announced in advance with a deprecation period preceding removal or reduction of support.
## Software
### Supported Operating Systems
- Systems with Microsoft* Windows* operating systems:
- Microsoft* Windows* 10
- Microsoft* Windows* 11
- Microsoft* Windows* Server 2019
- Microsoft* Windows* Server 2022
- Microsoft* Windows* Server 2025
- Systems with Linux* operating systems:
- Amazon* Linux 2023
- Debian* 12, 13
- Fedora* 43, 44
- Rocky* Linux* 9, 10
- Red Hat* Enterprise Linux* 8, 9, 10
- SuSE* Linux* Enterprise Server 15 SP6 and SP7
- SuSE* Linux* Enterprise Server 16
- Ubuntu* 24.04, 26.04
- Systems with macOS* operating systems:
- macOS* 12.x, 13.x, 14.x, 15.x
- Systems with Android* operating systems:
- Android* 9
### Community-Supported Platforms
- MinGW*
- FreeBSD*
- Microsoft* Windows* on ARM*/ARM64*
- macOS* on ARM64*
### Supported Compilers
- Intel* oneAPI DPC++/C++ Compiler
- Microsoft* Visual C++ 14.2 (Microsoft* Visual Studio* 2019, Windows* OS only)
- Microsoft* Visual C++ 14.3 (Microsoft* Visual Studio* 2022, Windows* OS only)
- Microsoft* Visual C++ 14.5 (Microsoft* Visual Studio* 2026, Windows* OS only)
- For each supported Linux* operating system, the standard gcc version provided with that operating system is supported:
- GNU Compilers (gcc) 8.x – 16.x
- GNU C Library (glibc) version 2.28 – 2.43
- Clang* 7.x - 22.x
## Limitations
There are some cases where we cannot provide support for your platforms. It includes:
1. The platform is out of official support (met end of life). When you use an unsupported platform, you can face a security risk that can be difficult to resolve.
2. We do not have the infrastructure to test a platform. Therefore we cannot guarantee that oneTBB works correctly on that platform.
3. Changes affect more code than just platform-specific macros.
4. The platform is incompatible with oneTBB. Some platforms may have limitations that prevent oneTBB from working correctly. We cannot provide support in these cases as the issue is beyond our control.
5. The platform is modified or customized. If you made significant updates to your platform, it might be hard for us to find the root cause of the issue. Therefore, we may not be able to provide support as the modification could affect the oneTBB functionality.
We understand that these limitations can be frustrating. Thus, we suggest creating a branch specifically for the unsupported platform, allowing other users to contribute to or use your implementation.
With semantic versioning, a MAJOR version increment generally means an incompatible API change,
while a MINOR version increment means added functionality that is implemented in a backwards compatible manner.
## The oneTBB Specification Version
The oneTBB project is governed by the [UXL foundation](https://uxlfoundation.org/) and has
[an open specification](https://oneapi-spec.uxlfoundation.org/specifications/oneapi/latest/elements/onetbb/source/nested-index).
Each release of the specification has a version number.
[As described in the specification](https://oneapi-spec.uxlfoundation.org/specifications/oneapi/latest/elements/onetbb/source/configuration/version_information),
the value of the `ONETBB_SPEC_VERSION` macro in `oneapi/tbb/version.h` is latest specification of oneTBB fully
supported by the implementation.
## The oneTBB Library Version
The oneTBB library version can be thought of as the name of the release. If you want to find a specific
release in the repository (https://github.com/uxlfoundation/oneTBB), the tag you would look for corresponds
to the oneTBB library version.
[As described in the specification](https://oneapi-spec.uxlfoundation.org/specifications/oneapi/latest/elements/onetbb/source/configuration/version_information),
the macros `TBB_VERSION_MAJOR`, `TBB_VERSION_MINOR`, `TBB_VERSION_STRING` in `oneapi/tbb/version.h`
provide the library version of the implementation that is being compiled against. The function
`const char* TBB_runtime_version();` can be used to query the library version of the oneTBB binary library that is
loaded at runtime.
## The oneTBB Interface Version
The oneTBB interface version is the public contract about the interface to the library including the
functions exported by the binary library and the types defined in the headers. The oneTBB library is designed
for backwards compatibility. It works well in the scenarios where components compile/link against a TBB version
X.Y. And then at runtime, the application loads a library version X.Z, where X.Z >= X.Y.
A minor version may add new functionality in the headers or in the binary library, including new entry points to the
binary library. An application compiled against an older minor version could not have used this new functionality
and therefore can safely use the newer binary library.
[As described in the specification](https://oneapi-spec.uxlfoundation.org/specifications/oneapi/latest/elements/onetbb/source/configuration/version_information),
the macros `TBB_INTERFACE_VERSION_MAJOR`, `TBB_INTERFACE_VERSION_MINOR`, `TBB_INTERFACE_VERSION` in `oneapi/tbb/version.h`
can be used to determine the interface version of the implementation that is being compiled against. The function
`int TBB_runtime_interface_version();` can be used to query the interface version of the oneTBB binary library that is
loaded at runtime.
### Shared Library Practices for Linux
On Linux we use a symlink system for binary libraries in the oneTBB distribution, and also explicitly set a soname.
The actual shared library is libtbb.so.X.Y but it is built with a –soname that uses only the major version number,
libtbb.so.X. In addition, there is a symlink from libtbb.so.X -> libtbb.so.X.Y and a symlink from
libtbb.so -> libtbb.so.X. Therefore, whether you build against libtbb.so, libtbb.so.X or libtbb.so.X.Y, your
application will have a dependency on libtbb.so.X.
A common development process is to compile and link against a library version X.Y. This creates
a dependency on libtbb.so.X. The packaged project then redistributes a TBB shared library that
is X.Z, where X.Z >= X.Y.
In the (unusual) case where the package does not redistribute a TBB library and instead depends on a version already
available on the install platform, it is safest to build against the oldest version you expect to encounter; in the
extreme this would be X.1. Of course, building against X.1 means no additional functionalility added in any later minor
release can be used during the development of the application.
### Shared Library Practices for Windows
On Windows, the TBB binary library has only the major version number, tbb12.dll.
## API versioning used to maintain backwards compatibility
This section is targeted at oneTBB contributors and will likely not be of interest to users of the
oneTBB library.
As mentioned previously, minor release may add new functionality, including modified definitions of classes
in the headers or new entry points into the binary library. To safely add this new functionality in a way
that avoids conflicts, oneTBB has namespaces for class definitions in the headers (that start with the
letter "d") and namespaces for symbols exported by the binary runtime library (that start with the
letter "r").
Below is an example of
[a function exported](https://github.com/uxlfoundation/oneTBB/blob/45c2298727d09556a523d6aeaec84ef23872eccf/src/tbb/parallel_pipeline.cpp#L446)
oneTBB extends its capabilities by offering robust support for ``WASM`` (see ``Limitation`` sections).
``WASM`` stands for WebAssembly, a low-level binary format for executing code in web browsers.
It is designed to be a portable target for compilers and efficient to parse and execute.
Using oneTBB with WASM, you can take full advantage of parallelism and concurrency while working on web-based applications, interactive websites, and a variety of other WASM-compatible platforms.
oneTBB offers WASM support through the integration with [Emscripten*](https://emscripten.org/docs/introducing_emscripten/index.html), a powerful toolchain for compiling C and C++ code into WASM-compatible runtimes.
## Build
**Prerequisites:** Download and install Emscripten*. See the [instructions](https://emscripten.org/docs/getting_started/downloads.html).
To compile oneTBB without ``pthreads``, set the flag ``-DEMSCRIPTEN_WITHOUT_PTHREAD=true`` in the command above. By default, oneTBB uses the ``pthreads``.
```
cmake --build . <options>
cmake --install . <options>
```
Where:
* ``emcmake`` - a tool that sets up the environment for Emscripten*.
* ``-DCMAKE_CXX_COMPILER=em++`` - specifies the C++ compiler as Emscripten* C++ compiler.
* ``-DCMAKE_C_COMPILER=emcc`` - specifies the C compiler as Emscripten* C compiler.
> **_NOTE:_** See [CMake documentation](https://github.com/uxlfoundation/oneTBB/blob/master/cmake/README.md) to learn about other options.
## Run Test
To run tests, use:
```
ctest
```
# Limitations
You can successfully build your application with oneTBB using WASM, but you may not achieve optimal performance immediately. This is due to the limitation with nested Web Workers: a Web Worker cannot schedule another worker without help from a browser thread. This can lead to unexpected performance outcomes, such as the application running in serial.
Find more information in the [issue](https://github.com/emscripten-core/emscripten/discussions/21963) in the Emscripten repository.
To workaround this issue, try one of the following ways:
1. **Recommended Solution: Use the ``-sPROXY_TO_PTHREAD`` Flag**.
This flag splits the initial thread into a browser thread and a main thread (proxied by a Web Worker), effectively resolving the issue as the browser thread is always present in the event loop and can participate in Web Workers scheduling. Refer to the [Emscripten documentation](https://emscripten.org/docs/porting/pthreads.html) for more details about ``-sPROXY_TO_PTHREAD`` since using this flag may require refactoring the code.
2. **Alternative Solution: Warm Up the oneTBB Thread Pool**
Initialize the oneTBB thread pool before making the first call to oneTBB. This approach forces the browser thread to participate in Web Workers scheduling.
```cpp
int num_threads = tbb::this_task_arena::max_concurrency();
The following controls are available during the configure stage:
```
TBB_TEST:BOOL - Enable testing (ON by default)
TBB_EXAMPLES:BOOL - Enable build of TBB examples (OFF by default)
TBB_STRICT:BOOL - Treat compiler warnings as errors (ON by default)
TBB_SANITIZE:STRING - Sanitizer parameter, passed to compiler/linker
TBB_SIGNTOOL:FILEPATH - Tool for digital signing, used in postinstall step for libraries if provided.
TBB_SIGNTOOL:FILEPATH - Tool for digital signing, used in post-install step for libraries if provided.
TBB_SIGNTOOL_ARGS:STRING - Additional arguments for TBB_SIGNTOOL, used if TBB_SIGNTOOL is set.
TBB4PY_BUILD:BOOL - Enable Intel(R) oneAPI Threading Building Blocks (oneTBB) Python module build (OFF by default)
TBB_CPF:BOOL - Enable preview features of the library (OFF by default)
BUILD_SHARED_LIBS:BOOL - Standard CMake variable controlling whether oneTBB is built as shared libraries (ON by default).
Setting it to OFF produces static archives; this configuration is highly discouraged and is not
supported. See "Building oneTBB as a Static Library" below.
TBB_BUILD:BOOL - Enable Intel(R) oneAPI Threading Building Blocks (oneTBB) build (ON by default)
TBB_FIND_PACKAGE - Enable search for external oneTBB using find_package instead of build from sources (OFF by default)
TBBMALLOC_BUILD:BOOL - Enable Intel(R) oneAPI Threading Building Blocks (oneTBB) memory allocator build (ON by default)
TBBMALLOC_PROXY_BUILD:BOOL - Enable Intel(R) oneAPI Threading Building Blocks (oneTBB) memory allocator proxy build (requires TBBMALLOC_BUILD. ON by default)
TBB4PY_BUILD:BOOL - Enable Intel(R) oneAPI Threading Building Blocks (oneTBB) Python module build (OFF by default)
TBB_INSTALL:BOOL - Enable installation (ON by default)
TBB_INSTALL_VARS:BOOL - Enable auto-generated vars installation(packages generated by `cpack` and `make install` will also include the vars script)(OFF by default)
TBB_VALGRIND_MEMCHECK:BOOL - Enable scan for memory leaks using Valgrind (OFF by default)
TBB_DISABLE_HWLOC_AUTOMATIC_SEARCH - Disable HWLOC automatic search by pkg-config tool (OFF by default)
TBB_ENABLE_IPO - Enable Interprocedural Optimization (IPO) during the compilation (ON by default)
TBB_CONTROL_FLOW_GUARD:BOOL - Enable Control Flow Guard (CFG) during the compilation (OFF by default)
TBB_BUILD_APPLE_FRAMEWORKS - Enable the Apple* frameworks instead of dylibs, only available on the Apple platform. (OFF by default)
TBB_FILE_TRIM - Enable __FILE__ trim, replace a build-time full path with a relative path in the debug info and macro __FILE__; use it to make
reproducible location-independent builds (ON by default)
TBB_VERIFY_DEPENDENCY_SIGNATURE - On Windows* enable verification of signatures for dependencies linked at run-time. (ON by default)
TBB_FUZZ_TESTING:BOOL - Enable fuzz testing (OFF by default)
TCM_BUILD - Enable Thread Composability Manager (TCM) build (ON by default)
```
## Configure, build and test
### Prerequisites
* CMake >= 3.1
## Configure, Build, and Test
### Preparation
In order to perform out-of-source build you have to create a build directory and go there:
To perform an out-of-source build, create a build directory and go there:
```bash
mkdir /tmp/my-build
@@ -37,22 +50,47 @@ cmake <options> <repo_root>
```
Some useful options:
-`-G <generator>` - specify particular project generator, see `cmake --help` for details.
-`-DCMAKE_BUILD_TYPE=Debug` - specify for Debug build, it isn't applicable for multi-config generators, e.g. for Visual Studio generator).
-`-G <generator>` - specify particular project generator. See `cmake --help` for details.
-`-DCMAKE_BUILD_TYPE=Debug` - specify for Debug build. It is not applicable for multi-config generators, e.g., Microsoft* Visual Studio* generator.
#### TBBBind library configuration
#### TBBBind Library Configuration
The TBBbind library has two versions: `tbbbind` and `tbbbind_2_0`. Each of these versions is linked with corresponding HWLOC library version: `tbbbind` links with HWLOC 1.11.x , `tbbbind_2_0` links with HWLOC 2.x.
> **_TIP:_** It is recommended to install the HWLOC* library. See [oneTBB documentation](https://uxlfoundation.github.io/oneTBB/GSG/next_steps.html#hybrid-cpu-and-numa-support) for details.
To enable the TBBBind library build or special tests that performed inside the HWLOC environment, please specify the following CMake variables:
The TBBbind library has three versions: `tbbbind`, `tbbbind_2_0`, and `tbbbind_2_5`. Each of these versions is linked with the corresponding HWLOC* library version:
-`tbbbind` links with `HWLOC 2.x` which was built as an archive library on Linux* (.a file) or a static library on Windows* (.lib file)
-`tbbbind_2_0` links with `HWLOC 2.1–2.4`
-`tbbbind_2_5` links with `HWLOC 2.5` and later
-`CMAKE_HWLOC_<HWLOC_VER>_LIBRARY_PATH` - path to the corresponding HWLOC version shared library on Linux or path to `.lib` file on Windows.
-`CMAKE_HWLOC_<HWLOC_VER>_INCLUDE_PATH` - path to the corresponding HWLOC version includes directory.
The search for a suitable version of the HWLOC library is enabled by default. If you want to use a specific version of the library, you can specify the path to it manually using the following CMake variables:
Windows requiresone additional variable for correct TBBBind library building:
-`CMAKE_HWLOC_<HWLOC_VER>_LIBRARY_PATH` - path to the corresponding HWLOC version shared library on Linux* OS or path to `.lib` file on Windows* OS
-`CMAKE_HWLOC_<HWLOC_VER>_INCLUDE_PATH` - path to the corresponding HWLOC version including directory
---
**NOTE:** Automatic HWLOC searching requires CMake version 3.6 or higher.
---
Windows* OS requires an additional variable for correct TBBBind library building:
-`CMAKE_HWLOC_<HWLOC_VER>_DLL_PATH` - path to the corresponding HWLOC version `.dll` file.
`HWLOC_VER`variable used above can be replaced with one of the two values:`1_11` for the `tbbbind` library configuration and `2` for the `tbbbind_2_0` library configuration.
The `HWLOC_VER`substring used earlier can be replaced with one of the three values:
-`STATIC` for the `tbbbind` library configuration
-`2` for the `tbbbind_2_0` library configuration
-`2_5` for the `tbbbind_2_5` library configuration
If you specify variables for several TBBBind versions, the building process for all of these versions is performed during a single build session.
---
**TIP**
Specify the `TBB_DISABLE_HWLOC_AUTOMATIC_SEARCH` to turn off the HWLOC library's automatic search.
---
### Build
@@ -61,21 +99,28 @@ cmake --build . <options>
```
Some useful options:
-`--target <target>` - specific target, "all" is default.
-`--config <Release|Debug>` - build configuration, applicable only for multi-config generators, e.g. Visual Studio generator.
-`--target <target>` - specific target, "all" is the default.
-`--config <Release|Debug>` - build configuration, applicable only for multi-config generators, e.g., Visual Studio* generator.
Binaries are placed to `./<compiler-id>_<compiler-ver>_cxx<stdver>_<build-type>` (for example, `./gnu_4.8_cxx11_release`)
The binaries are placed to `./<compiler-id>_<compiler-ver>_cxx<stdver>_<build-type>`. For example, `./gnu_4.8_cxx11_release`.
#### Build for 32-bit
#### Build For 32-bit
* Intel Compiler: just source Intel(R) C++ Compiler with `ia32` and build as usual.
* MSVC: use switch for [generator](https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html) (e.g. `-A Win32` for [VS2019](https://cmake.org/cmake/help/latest/generator/Visual%20Studio%2016%202019.html)) during the configuration stage and then build as usual.
* GCC/Clang: specify `-m32` during the configuration:`CXXFLAGS=-m32 cmake ..` or `cmake -DCMAKE_CXX_FLAGS=-m32 ..`
*Any other compiler which builds for 64-bit by default: specify 32-bit compiler key during the configuration as above.
***Intel(R) Compiler**. Source Intel(R) C++ Compiler with `ia32` and build as usual.
***MSVC**. Use switch for [generator](https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html) (e.g.,`-A Win32` for [VS2019](https://cmake.org/cmake/help/latest/generator/Visual%20Studio%2016%202019.html)) during the configuration stage and then build as usual.
***GCC/Clang**. Specify `-m32` during the configuration. It can be`CXXFLAGS=-m32 cmake ..` or `cmake -DCMAKE_CXX_FLAGS=-m32 ..`
*For any other compiler, which builds for 64-bit by default, specify a 32-bit compiler key during the configuration as above.
#### Windows specific builds (CMake 3.15 or newer is required)
#### Windows* OS-Specific Builds
* Dynamic linkage with CRT: default behavior, can be explicitly specified by setting `CMAKE_MSVC_RUNTIME_LIBRARY` to `MultiThreadedDLL` or `MultiThreadedDebugDLL`.
---
**NOTE**
The following builds require CMake version 3.15 or higher.
---
* **Dynamic linkage with C Runtime Library (CRT)**. The default behavior can be explicitly specified by setting `CMAKE_MSVC_RUNTIME_LIBRARY` to `MultiThreadedDLL` or `MultiThreadedDebugDLL`.
The library path points to a file, while the include path points to a directory and not to ``hwloc.h``.
---
### Test
#### Build test
Using default ('all') target:
To build a test, use the default target ``all``:
```
cmake --build .
```
or using specific test target:
Or use a specific test target:
```
cmake --build . --target <test> # e.g. test_version
```
#### Run test
#### Run Test
Using CTest:
You can run a test by using CTest:
```bash
ctest
```
or using 'test' target:
Or by using the ``test`` target:
```bash
cmake --build . --target test# currently doesn't work on Windows
cmake --build . --target test # currently does not work on Windows* OS
```
## Sanitizers - сonfigure, build and run
## Building oneTBB as a Static Library
---
**CAUTION**
Static linking of oneTBB is highly discouraged and has limited support.
---
**IMPORTANT**
oneTBB manages a resource that is owned by the whole program - the machine's hardware threads - so its task scheduler and worker thread pool are intended to be a process-wide singleton.
---
See [Static Linking of oneTBB](https://uxlfoundation.github.io/oneTBB/main/intro/static_linking.html) for the rationale, the features that become unavailable, and the risks of ending up with more than one copy of oneTBB in a process. If you choose this configuration, validating your application is your responsibility.
oneTBB is built as a shared library by default. To build static archives instead, set `BUILD_SHARED_LIBS` to `OFF` during the configuration:
Windows* OS | `tbb12.lib`, `tbbmalloc.lib` | `tbb12_debug.lib`, `tbbmalloc_debug.lib`
### Effects on the Build Configuration
Setting `BUILD_SHARED_LIBS` to `OFF` also changes the following:
`CMAKE_POSITION_INDEPENDENT_CODE` is set to `ON` so that the archive can be linked into a shared object.
It is only defaulted, so an explicit value specified during the configuration is respected.
The `tbbbind` proxy libraries are loaded at run time, which a static build does not support, so they
are skipped and the configuration step reports `TBBBind build targets are disabled due to
unsupported environment`. As a result, `tbb::info` and `tbb::task_arena::constraints` cannot
report or apply topology-based constraints. See [TBBBind Library Configuration](#tbbbind-library-configuration).
`tbbmalloc_proxy` is not built even though `TBBMALLOC_PROXY_BUILD` is `ON` by default.
The proxy replaces the memory allocation functions of the C library, which requires a
shared library. The scalable allocator is still available through the explicit interfaces,
such as `tbb::scalable_allocator` and `scalable_malloc`.
oneTBB loads the TCM library dynamically, so a static build cannot coordinate with
other threading runtimes through it, regardless of `TCM_BUILD` or the `TCM_ENABLE`
environment variable.
IPO is applied only to shared library builds, so `TBB_ENABLE_IPO=ON` has no effect and a
static oneTBB may be marginally slower than the shared one.
On Windows* OS, `BUILD_SHARED_LIBS` controls how oneTBB itself is linked, not how oneTBB
links the CRT. To link the CRT statically as well, set `CMAKE_MSVC_RUNTIME_LIBRARY`.
See [Windows* OS-Specific Builds](#windows-os-specific-builds).
### Consuming a Static Build
Consuming a static build works the same way as a shared one. The generated `TBBConfig.cmake` adds a `Threads` dependency for static builds, so the platform thread library is linked transitively:
```cmake
find_package(TBB REQUIRED)
target_link_libraries(my_app PRIVATE TBB::tbb)
```
See [TBBConfig - Integration of Binary Packages](#tbbconfig---integration-of-binary-packages) for details about the configuration module.
---
**WARNING**
Static builds receive only light validation coverage. The tests that depend on HWLOC or on `tbbmalloc_proxy` are excluded automatically, so a passing `ctest` run does not indicate the same coverage as it does for a shared build.
make -j memcheck-<test name> # or memcheck-all to scan all tests
```
## Test specification (Doxygen)
## Test Specification
Use Doxygen* to generate oneTBB test specification:
```bash
mkdir build
@@ -160,35 +316,12 @@ cmake -DTBB_TEST_SPEC=ON ..
make test_spec
```
## Intallation and packaging
## TBBConfig - Integration of Binary Packages
**NOTE: be careful about installation: avoid commands like `make install` unless you fully understand the consequences.**
It is a configuration module that is used for the integration of prebuilt oneTBB. It consists of two files (``TBBConfig.cmake`` and ``TBBConfigVersion.cmake``) and can be used via the [find_package](https://cmake.org/cmake/help/latest/command/find_package.html) function.
The following install components are supported:
-`runtime` - oneTBB runtime package (core shared libraries and `.dll` files on Windows).
-`devel` - oneTBB development package (header files, CMake integration files, library symbolic links and `.lib` files on Windows).
-`tbb4py` - [oneTBB Module for Python](#onetbb-python-module-support).
How to install specific components after configuration and build:
The following commands allow to create a simple portable package which includes header files, libraries and integration files for CMake:
```bash
cmake <options> ..
cpack
```
## TBBConfig - integration of binary packages
It is a configuration module that is used for integration of prebuilt oneTBB. It consists of two files (TBBConfig.cmake and TBBConfigVersion.cmake) and can be used via [find_package](https://cmake.org/cmake/help/latest/command/find_package.html) function.
How to use this module in your CMake project:
1. Let CMake know where to search for TBBConfig, e.g. specify location of TBBConfig.cmake in `TBB_DIR` (for more details about search paths see [find_package](https://cmake.org/cmake/help/latest/command/find_package.html)).
To use this module in your CMake project:
1. Let CMake know where to search for TBBConfig, e.g. specify the location of ``TBBConfig.cmake`` in `TBB_DIR` (for more details about search paths, see [find_package](https://cmake.org/cmake/help/latest/command/find_package.html)).
2. Use [find_package](https://cmake.org/cmake/help/latest/command/find_package.html) to find oneTBB.
3. Use provided variables and/or imported targets (described below) to work with the found oneTBB.
oneTBB components can be passed to [find_package](https://cmake.org/cmake/help/latest/command/find_package.html) after keyword ``COMPONENTS`` or ``REQUIRED``.
Use basic names of components (`tbb`, `tbbmalloc`, etc.).
If components are not specified then the default set is used: `tbb`, `tbbmalloc` and ``tbbmalloc_proxy``.
If components are not specified, then the default set is used: `tbb`, `tbbmalloc`, and ``tbbmalloc_proxy``.
If `tbbmalloc_proxy` is requested, `tbbmalloc` component will also be added and set as dependency for `tbbmalloc_proxy`.
If `tbbmalloc_proxy` is requested, the `tbbmalloc` component is also added and set as a dependency for `tbbmalloc_proxy`.
TBBConfig creates [imported targets](https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#imported-targets>) as
shared libraries using the following format: `TBB::<component>` (for example, `TBB::tbb`, `TBB::tbbmalloc`).
shared libraries using the following format: `TBB::<component>`. For example, `TBB::tbb` or `TBB::tbbmalloc`.
Set `TBB_FIND_RELEASE_ONLY` to `TRUE` before calling `find_package` in order to search only for release oneTBB version. This variable helps to avoid simultaneous linkage of release and debug oneTBB versions when CMake configuration is `Debug` but a third-party component depends on release oneTBB version.
To search only for release oneTBB version, set `TBB_FIND_RELEASE_ONLY` to `TRUE` before calling `find_package`. This variable helps to avoid simultaneous linkage of release and debug oneTBB versions when CMake configuration is `Debug,` but a third-party component depends on the release oneTBB version.
Variables set during TBB configuration:
@@ -221,14 +354,14 @@ Variable | Description
`TBB_VERSION` | oneTBB version (format: `<major>.<minor>.<patch>.<tweak>`)
`TBB_IMPORTED_TARGETS` | All created oneTBB imported targets (not supported for builds from source code)
Starting from [oneTBB 2021.1](https://github.com/oneapi-src/oneTBB/releases/tag/v2021.1) GitHub release TBBConfig files in the binary packages are located under `<tbb-root>/lib/cmake/TBB`.
Starting from [oneTBB 2021.1](https://github.com/uxlfoundation/oneTBB/releases/tag/v2021.1), GitHub* release TBBConfig files in the binary packages are located under `<tbb-root>/lib/cmake/TBB`.
For example, `TBB_DIR` should be set to `<tbb-root>/lib/cmake/TBB`.
TBBConfig files are automatically created during the build from source code and can be installed together with the library.
Also oneTBB provides a helper function that creates TBBConfig files from predefined templates: see `tbb_generate_config` in `cmake/config_generation.cmake`.
Also, oneTBB provides a helper function that creates TBBConfig files from predefined templates. See `tbb_generate_config` in `cmake/config_generation.cmake`.
## oneTBB Python Module support
`TBB4PY_BUILD` Cmake option provides ability to build Python module for oneTBB.
## oneTBB Python Module Support
The `TBB4PY_BUILD` Cmake option provides the ability to build a Python module for oneTBB.
### Targets:
- `irml` - build IPC RML server
@@ -238,30 +371,30 @@ Also oneTBB provides a helper function that creates TBBConfig files from predefi
- Python version 3.5 or newer
- SWIG version 3.0.6 or newer
## CMake files
## CMake Files
### Compile/link options
### Compile and Link Options
Compile and link options may be specific for certain compilers. This part is handled in `cmake/compilers/*` files.
Options in TBB CMake are handled via variables in two ways for convenience:
* by options group
* by specific option
* by the specific option
#### Options group
#### Options Group
Naming convention is the following: `TBB_<SCOPE>_<STAGE>_<CATEGORY>`, where
Naming convention is the following: `TBB_<SCOPE>_<STAGE>_<CATEGORY>`, where:
* `<SCOPE>` could be
* `<SCOPE>` can be:
* `LIB` - options applied during libraries build.
* `TEST` - options applied during test build.
* `BENCH` - options applied during benchmarks build.
* `COMMON` - options applied during all (libraries, test, benchmarks) builds.
* `<STAGE>` could be
* `<STAGE>` can be:
* `COMPILE` - options applied during the compilation.
* `LINK` - options applied during the linkage.
* `<CATEGORY>` could be
* `<CATEGORY>` can be:
* `FLAGS` - list of flags
* `LIBS` - list of libraries
@@ -269,16 +402,17 @@ Naming convention is the following: `TBB_<SCOPE>_<STAGE>_<CATEGORY>`, where
Variable | Description
--- | ---
`TBB_COMMON_COMPILE_FLAGS` | Applied to libraries, tests and benchmarks as compile options
`TBB_COMMON_COMPILE_FLAGS` | Applied to libraries, tests, and benchmarks as compile options
`TBB_LIB_LINK_FLAGS` | Applied to libraries as link options
`TBB_LIB_LINK_LIBS ` | Applied to libraries as link libraries
`TBB_TEST_COMPILE_FLAGS` | Applied to tests as compile options
Specify the `LINK` options prefixed with a dash(-) for MSVC(Visual Studio) compiler with CMake < 3.13 to avoid issues caused by `target_link_libraries` CMake command usage.
#### Specific options
#### Specific Options
If the option used only in part of the places (library, tests, benchmarks) as well as adding this option to the group of other options is not possible,
If the option is used only in part of the places (library, tests, benchmarks) and adding this option to the group of other options is not possible,
then the option must be named using common sense.
Warnings supperssions should be added into `TBB_WARNING_SUPPRESS` variable which is applied during the compilation of libraries, tests and benchmarks.
Additional warnings should be added into `TBB_WARNING_TEST_FLAGS` variable which is applied during the compilation of tests.
Warning suppressions should be added to the `TBB_WARNING_SUPPRESS` variable, which is applied during the compilation of libraries, tests, and benchmarks.
Additional warnings should be added to the `TBB_WARNING_TEST_FLAGS` variable, which is applied during the compilation of tests.
|short_name| Get Started Guide provides the information you need to begin working with oneTBB.
It is helpful for new users of parallel programming and experienced developers that want to improve code performance.
It is recommended for you to have a basic knowledge of C++ programming and some experience with parallel programming concepts.
|full_name| is a runtime-based parallel programming model for C++ code that uses tasks.
The template-based runtime library can help you harness the latent performance of multi-core processors.
oneTBB enables you to simplify parallel programming by breaking computation into parallel running tasks. Within a single process,
parallelism is carried out by mapping tasks to threads. Threads are an operating system mechanism that allows the same or different sets of instructions
to be executed simultaneously. Using threads can make your program work faster and more efficiently.
Here you can see one of the possible executions of tasks by threads.
..figure:: /GSG/Images/how-oneTBB-works.png
:scale:70%
:align:center
Use oneTBB to write scalable applications that:
* Specify logical parallel structure instead of threads.
* Emphasize data-parallel programming.
* Take advantage of concurrent collections and parallel algorithms.
oneTBB supports nested parallelism and load balancing. It means that you can use the library without worrying about oversubscribing a system, which happens when more tasks are assigned to a system than it can handle efficiently.
oneTBB is used in different areas, such as scientific simulations, gaming, data analysis, etc.
It is available as a stand-alone product and as part of the |toolkit|.
After installing oneTBB, complete the following steps to start working with the library.
Set the Environment Variables
*****************************
After installing |short_name|, set the environment variables:
#. Go to the oneTBB installation directory.
#. Set the environment variables using the script in ``<install_dir>`` by running:
* On Linux* OS: ``vars.{sh|csh} in <install_dir>/tbb/latest/env``
* On Windows* OS: ``vars.bat in <install_dir>/tbb/latest/env``
..tip::
oneTBB can coordinate with Intel(R) OpenMP on CPU resources usage to avoid
excessive oversubscription when both runtimes are used within a process. To
enable this feature set ``TCM_ENABLE`` environment variable to ``1``. For
more details, see :ref:`avoid_cpu_overutilization`.
Build and Run a Sample
**********************
..tab-set::
..tab-item:: Windows* OS
#. Create a new C++ project using your IDE. In this example, Microsoft* Visual Studio* Code is used.
#. Create an ``example.cpp`` file in the project.
#. Copy and paste the code below. It is a typical example of a |short_name| algorithm. The sample calculates a sum of all integer numbers from 1 to 100.
..code::
#include <oneapi/tbb.h>
int main (){
int sum = oneapi::tbb::parallel_reduce(
oneapi::tbb::blocked_range<int>(1,101), 0,
[](oneapi::tbb::blocked_range<int> const& r, int init) -> int {
for (int v = r.begin(); v != r.end(); v++) {
init += v;
}
return init;
},
[](int lhs, int rhs) -> int {
return lhs + rhs;
}
);
printf("Sum: %d\n", sum);
return 0;
}
#. Open the ``tasks.json`` file in the ``.vscode`` directory and paste the following lines to the args array:
* ``-Ipath/to/oneTBB/include`` to add oneTBB include directory.
#. If oneTBB is configured correctly, the output displays ``Sum: 5050``.
..tab-item:: Linux* OS
#. Create an ``example.cpp`` file in the project.
#. Copy and paste the code below. It is a typical example of a |short_name| algorithm. The sample calculates a sum of all integer numbers from 1 to 100.
..code::
#include <oneapi/tbb.h>
int main(){
int sum = oneapi::tbb::parallel_reduce(
oneapi::tbb::blocked_range<int>(1,101), 0,
[](oneapi::tbb::blocked_range<int> const& r, int init) -> int {
for (int v = r.begin(); v != r.end(); v++) {
init += v;
}
return init;
},
[](int lhs, int rhs) -> int {
return lhs + rhs;
}
);
printf("Sum: %d\n", sum);
return 0;
}
#. Compile the code using oneTBB. For example,
..code-block::
g++ -std=c++11 example.cpp -o example -ltbb
#. Run the executable:
..code-block::
./example
#. If oneTBB is configured correctly, the output displays ``Sum: 5050``.
Enable Hybrid CPU and NUMA Support
***********************************
To support Hybrid CPU and NUMA platforms, oneTBB relies on the HWLOC* library.
The HWLOC functionality is accessed through a set of proxy libraries whose names begin with the ``tbbbind`` prefix. oneTBB automatically loads them at runtime when needed. To find and load these libraries successfully, locate them in the same directory as the oneTBB library itself (e.g., alongside ``libtbb.so`` or ``tbb.dll``).
Starting with oneTBB 2022.2, the default ``tbbbind`` library is statically linked with HWLOC 2.x. This version is used if a system-provided HWLOC cannot be found.
If you prefer to use a system-provided or custom-built version of HWLOC, make sure it is available in the search paths used by the dynamic loader. Consult your platform’s dynamic loader documentation for details about these paths (e.g., ``LD_LIBRARY_PATH`` on Linux* OS or ``PATH`` on Windows* OS).
To use a specific HWLOC version, place one of the following tbbbind variants in the same directory as the oneTBB library:
* ``tbbbind_2_5`` — depends on HWLOC version 2.5 or higher. Use this version if hybrid CPU support is required.
* ``tbbbind_2_0`` — depends on HWLOC versions 2.1 to 2.4.
..tip:: To confirm that tbbbind is loaded successfully at runtime, set the environment variable ``TBB_VERSION=1`` before launching your application.
* `A solution to the binpacking problem using a queue_node, a buffer_node, and function_node. <https://github.com/uxlfoundation/oneTBB/tree/master/examples/graph/binpack>`_
* `An implementation of dining philosophers in graph using the reserving join_node <https://github.com/uxlfoundation/oneTBB/tree/master/examples/graph/dining_philosophers>`_
* `A parallel implementation of bzip2 block-sorting file compressor <https://github.com/uxlfoundation/oneTBB/tree/master/examples/graph/fgbzip2>`_
* `An example of a collection of digital logic gates that can be easily composed into larger circuits <https://github.com/uxlfoundation/oneTBB/tree/master/examples/graph/logic_sim>`_
* `An example of a Kohonen Self-Organizing Map using cancellation <https://github.com/uxlfoundation/oneTBB/tree/master/examples/graph/som>`_
* `Split computational kernel for execution between CPU and GPU <https://github.com/uxlfoundation/oneTBB/tree/master/examples/sycl/tbb-async-sycl>`_
* `Find largest matching substrings <https://github.com/uxlfoundation/oneTBB/tree/master/examples/getting_started>`_
* `Resumable task: Split computational kernel for execution between CPU and GPU <https://github.com/uxlfoundation/oneTBB/tree/master/examples/sycl/tbb-resumable-tasks-sycl>`_
* `Execute similar computational kernels, with one task executing the SYCL* code and the other task executing the oneTBB code <https://github.com/uxlfoundation/oneTBB/tree/master/examples/sycl/tbb-task-sycl>`_
* **Other**
* `Compute Fibonacci numbers in different ways <https://github.com/uxlfoundation/oneTBB/tree/master/examples/test_all>`_
..note:: You can also refer to the `oneAPI Samples <https://oneapi-src.github.io/oneAPI-samples/>`_ to learn more about the ecosystem.
- :onetbb-spec:`Function create_numa_task_arenas introduced to create a set of NUMA bound arenas <task_scheduler/task_arena/task_arena_cls>`
- :doc:`Additional deduction guides for flow graph <../tbb_userguide/fg_ctad>`
- :onetbb-spec:`Additional deduction guides for blocked_range_nd <algorithms/blocked_ranges/blocked_nd_range_cls>`
- flow graph :onetbb-spec:`indexer_node <flow_graph/indexer_node_cls>` and :onetbb-spec:`join_node <flow_graph/join_node_cls>` now support 10 or more input ports
- :doc:`Preview Feature: wait for single task in task_group <../reference/task_group_ext/wait_single_task>`
- :doc:`Preview Feature: resource_limited_node and resource_limiter classes <../reference/fg_resource_limiting>`
- :doc:`Preview Feature: global control parameter for default block time behavior <../reference/parallel_phase_for_task_arena>`
**ABI Changes:**
- ordered container layout changes for scalability improvements that impact concurrent_map, concurrent_multimap, concurrent_set,
and concurrent_multiset
**Notes:**
The ABI is backwards compatible but issues can arise for partial recomplilation cases when objects with modified layouts are passed
across compilation units built against headers with the older layout.
.._version-2022.3.0:
2022.3.0
~~~~~~~~
**API Changes:**
- :onetbb-spec:`task_arena::enqueue and task_arena::wait_for to enqueue to and wait for specific task_group <task_scheduler/task_arena/task_arena_cls>`
- :doc:`custom assertion handler support <../reference/assertion_handler>`
set/get_assertion_handler symbols are used by custom assertion handler support, current_task_ptr is used by preview of task_group dependencies
.._version-2022.2.0:
2022.2.0
~~~~~~~~
No API or ABI changes in this release.
.._version-2022.1.0:
2022.1.0
~~~~~~~~
**API Changes:**
- `Added explicit deduction guides for blocked_nd_range <https://github.com/uxlfoundation/oneTBB/tree/v2022.1.0/rfcs/experimental/blocked_nd_range_ctad>`_
- `preview of parallel phase <https://github.com/uxlfoundation/oneTBB/tree/v2022.1.0/rfcs/experimental/parallel_phase_for_task_arena>`_
**ABI Changes:**
- enter/exit_parallel_phase
**Notes:**
enter/exit_parallel_phase is only used by preview of parallel phase. **WARNING:** there was temporary, inadvertent change that made the `unsafe_wait <https://oneapi-spec.uxlfoundation.org/specifications/oneapi/latest/elements/onetbb/source/task_scheduler/scheduling_controls/task_scheduler_handle_cls>`_ exception local for this release only.
.._version-2022.0.0:
2022.0.0
~~~~~~~~
**API Changes:**
- `Preview of flow graph try_put_and_wait <https://github.com/uxlfoundation/oneTBB/pull/1513>`_
**ABI Changes:**
- get_thread_reference_vertex
- execution_slot
**Notes:**
`The layouts of task_group and flow::graph were changed to improve scalability. The binary library is backwards compatible
but issues can arise for partial recomplilation cases (see linked discussion) <https://github.com/uxlfoundation/oneTBB/discussions/1371>`_. get_thread_reference_vertex and execution_slot added for scalability improvements.
.._version-2021.13.0:
2021.13.0
~~~~~~~~~
**API Changes:**
- `Better rvalues support for parallel_reduce and parallel_deterministic_reduce functional API <https://github.com/uxlfoundation/oneTBB/pull/1307>`_
**ABI Changes:**
No ABI changes in this release.
.._version-2021.12.0:
2021.12.0
~~~~~~~~~
No API or ABI changes in this release.
.._version-2021.11.0:
2021.11.0
~~~~~~~~~
No API or ABI changes in this release.
**Notes:**
Thread Composability Manager support introduced. It can be enabled by setting "TCM_ENABLE" environmental variable to 1
.._version-2021.10.0:
2021.10.0
~~~~~~~~~
**API Changes:**
- `parallel algorithms and Flow Graph nodes allowed to accept pointers to the member functions and member objects as the user-provided callables <https://github.com/uxlfoundation/oneTBB/pull/880>`_
- `Added missed member functions, such as assignment operators and swap function, to the concurrent_queue and concurrent_bounded_queue containers <https://github.com/uxlfoundation/oneTBB/pull/1033>`_
**ABI Changes:**
No ABI changes in this release.
.._version-2021.9.0:
2021.9.0
~~~~~~~~
**API Changes:**
- `Hybrid core type constraints are fully supported and no longer guarded by preview macro <https://oneapi-spec.uxlfoundation.org/specifications/oneapi/v1.2-rev-1/elements/onetbb/source/task_scheduler/task_arena/task_arena_cls#_CPPv4N11constraints9core_typeE>`_
**ABI Changes:**
No ABI changes in this release.
**Notes:**
Hybrid CPU support is now production features, including use of symbols introduced in 2021.2.0
.._version-2021.8.0:
2021.8.0
~~~~~~~~
**API Changes:**
- `Fixed concurrent_bounded_queue return type to match specification <https://github.com/uxlfoundation/oneTBB/issues/807>`_
**ABI Changes:**
No ABI changes in this release.
.._version-2021.7.0:
2021.7.0
~~~~~~~~
No API or ABI changes in this release.
.._version-2021.6.0:
2021.6.0
~~~~~~~~
**API Changes:**
- `Improved support and use of the latest C++ standards for parallel_sort that allows using this algorithm with user-defined and standard library-defined objects with modern semantics <https://oneapi-spec.uxlfoundation.org/specifications/oneapi/v1.2-rev-1/elements/onetbb/source/algorithms/functions/parallel_sort_func>`_
- The following features are now fully functional: `task_arena extensions <https://oneapi-spec.uxlfoundation.org/specifications/oneapi/v1.2-rev-1/elements/onetbb/source/task_scheduler/task_arena/task_arena_cls>`_, `collaborative_call_once <https://oneapi-spec.uxlfoundation.org/specifications/oneapi/latest/elements/onetbb/source/algorithms/functions/collaborative_call_once_func>`_, heterogeneous overloads for concurrent_hash_map, and `task_scheduler_handle <https://oneapi-spec.uxlfoundation.org/specifications/oneapi/v1.2-rev-1/elements/onetbb/source/task_scheduler/scheduling_controls/task_scheduler_handle_cls>`_
**ABI Changes:**
No ABI changes in this release.
.._version-2021.5.0:
2021.5.0
~~~~~~~~
**API Changes:**
- Preview of task_group interface with a new run_and_wait overload to accept task_handle
**ABI Changes:**
No ABI changes in this release.
.._version-2021.4.0:
2021.4.0
~~~~~~~~
**API Changes:**
- Preview of collaborative_call_once algorithm
**ABI Changes:**
- notify_waiters
.._version-2021.3.0:
2021.3.0
~~~~~~~~
**API Changes:**
- Extended the high-level task API to simplify migration from TBB to oneTBB
- Added mutex and rw_mutex that are suitable for long critical sections and resistant to high contention
- Added ability to customize the concurrent_hash_map mutex type
- Added heterogeneous lookup, erase, and insert operations to concurrent_hash_map
This page outlines the known limitations of oneTBB to help you better understand its capabilities.
Debug TBB In The SYCL Program
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**Limitation:** The application may crash when using the Debug version of oneTBB in a SYCL program compiled with Intel(R) oneAPI DPC++/C++ Compiler. This happens because both ``tbb`` (Release version) and ``tbb_debug`` (Debug version) libraries load simultaneously, causing conflicts.
**Solution:** Do one of the following:
* Link the application with the Release version ``tbb`` instead of ``tbb_debug``.
* Use the ``qtbb`` flag provided by the Intel(R) oneAPI DPC++/C++ Compiler.
Static Linking Possible But Not Recommended
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**Limitation:** Building and using oneTBB as a static library reduces the benefits of the shared thread pool and limits library functionality.
**Risks:** See :ref:`Static Linking of oneTBB <static_linking>` for why the shared library is the preferred form, which features are unavailable in a static library, and the risks of having more than one copy of oneTBB in a process.
**Solution:** Prefer the shared library. If a static library is required, follow :ref:`Recommendations If You Must Link Statically <static_linking_recommendations>` and see `Building oneTBB as a Static Library <https://github.com/uxlfoundation/oneTBB/blob/master/cmake/README.md#building-onetbb-as-a-static-library>`_ for build instructions.
Freestanding Compilation Mode
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**Limitation:** oneTBB does not support the freestanding compilation mode.
**Risk:** Compiling an application that utilizes oneTBB headers using the Intel(R) oneAPI DPC++/C++ Compiler may result in failure on Windows* OS if the ``/Qfreestanding`` compiler option is employed.
Static Assert
^^^^^^^^^^^^^
**Limitation:** A static assert causes the compilation failures in oneTBB headers if the following conditions are satisfied:
* Compilation is done with Clang 12.0.0 or a more recent version.
* The LLVM standard library is employed, coupled with the use of the ``-ffreestanding`` flag and C++11/14 compiler options.
**Risk:** The compilation failures.
Interface Incompatibilities: TBB vs oneTBB
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**Limitation:** An application using Parallel STL algorithms in the ``libstdc++`` versions 9 and 10 may fail to compile due to incompatible interface changes between earlier versions of Threading Building Blocks (TBB) and oneAPI Threading Building Blocks (oneTBB).
**Solution:** Disable support for Parallel STL algorithms by defining ``PSTL_USE_PARALLEL_POLICIES`` (in libstdc++ 9) or ``_GLIBCXX_USE_TBB_PAR_BACKEND`` (in libstdc++ 10) macro to zero before inclusion of the first standard header file in each translation unit.
Incorrect Installation Location
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**Limitation:** On Linux* OS, if oneAPI Threading Building Blocks (oneTBB) or Threading Building Blocks (TBB) are installed in a system folder, such as ``/usr/lib64``, the application may fail to link due to the order in which the linker searches for libraries.
**Risk:** The issue does not affect the program execution.
**Solution:** Use the ``-L`` linker option to specify the correct location of oneTBB library.
``fork()`` Support
^^^^^^^^^^^^^^^^^^^
**Limitation:** oneTBB does not support ``fork()``.
**Solution:** To work-around the issue, consider using ``task_scheduler_handle`` to join oneTBB worker threads before using ``fork()``.
Dynamic Malloc Replacement and Topology API Incompatibilities
**Limitation:** On Linux* OS, using dynamic malloc replacement with ``tbb::info`` and ``tbb::task_arena::constraints`` APIs may result in runtime failures.
**Solution:** Set ``TBB_ENABLE_SANITIZERS=1`` in the environment. This informs that dynamic malloc replacement is used.
The following conventions may be used in this document.
..container:: tablenoborder
..list-table::
:header-rows:1
* - Convention
- Explanation
- Example
* - \ *Italic*
- Used for introducing new terms, denotation of terms, placeholders, or titles of manuals.
- The filename consists of the *basename* and the *extension*.
* - \ ``Monospace``
- Indicates directory paths and filenames, commands and command line options, function names, methods, classes, data structures in body text, source code.
- \ ``ippsapi.h`` \ ``\alt\include`` Use the okCreateObjs() function to... \ ``printf("hello, world\n");``
* - [ ]
- Items enclosed in brackets are optional.
- Fa[c] Indicates Fa or Fac.
* - { \| }
- Braces and vertical bars indicate the choice of one item from a selection of two or more items.
- X{K \| W \| P} Indicates XK, XW, or XP.
* - "[" "]" "{" | " }" "|"
- Writing a metacharacter in quotation marks negates the syntactical meaning stated above; | the character is taken as a literal.
- "[" X "]" [ Y ] Denotes the letter X enclosed in brackets, optionally followed by the letter Y.
* - ...
- The ellipsis indicates that the previous item can be repeated several times.
- \ ``filename`` ... Indicates that one or more filenames can be specified.
* - ,...
- The ellipsis preceded by a comma indicates that the previous item can be repeated several times, | separated by commas.
- \ ``word`` ,... Indicates that one or more words can be specified. If more than one word is specified, the words are comma-separated.
..container:: section
Class members are summarized by informal class declarations that
describe the class as it seems to clients, not how it is actually
implemented. For example, here is an informal declaration of class
``Foo``:
::
class Foo {
public:
int x();
int y;
~Foo();
};
The actual implementation might look like:
::
namespace internal {
class FooBase {
protected:
int x();
};
class Foo_v3: protected FooBase {
private:
int internal_stuff;
public:
using FooBase::x;
int y;
};
}
typedef internal::Foo_v3 Foo;
The example shows two cases where the actual implementation departs
from the informal declaration:
- ``Foo`` is actually a typedef to ``Foo_v3``.
- Method ``x()`` is inherited from a protected base class.
- The destructor is an implicit method generated by the compiler.
The informal declarations are intended to show you what you need to
know to use the class without the distraction of irrelevant clutter
There are four main types of errors/hazards you can encounter in the development of libraries for parallelism:
* Interface correspondence to specification
* Memory errors
* Data race
* Race conditions and deadlocks
|short_name| testing approach is designed to provide high coverage of these error types.
All types of errors are covered with unit testing and code review.
Code coverage metrics are tracked to ensure high code coverage with tests. Uncovered branches are analyzed manually.
Memory errors and data races are additionally covered by special tools that include thread and memory sanitizers.
Race conditions and deadlocks are the most complicated errors.
They are covered by:
* **Unit tests** that, however, have limited capability to catch such errors.
* **Integration tests**. Multiple different functionalities are heavily combined to emulate user use cases that may trigger such errors based on prior knowledge and expertise.
* **Stress testing with different possible combinations**. It ensures that even rarely triggered error conditions are caught by testing.
..note:: Every fix is required to be covered by a regression test to guarantee the detection of such issues in the future.
Continuous Integration triggers all the tests on each commit. This ensures that:
* Issues are detected, starting from the early development phase and up to the moment of integration of changes into the library.
* The highest quality of the library is maintained even in such error-prone domains as parallelism.
To enable this feature, set the ``TBB_PREVIEW_TASK_ARENA_CORE_TYPE_SELECTOR`` macro to 1. When available and enabled, the feature-test macro ``TBB_HAS_TASK_ARENA_CORE_TYPE_SELECTOR`` is defined.
..contents::
:local:
:depth:2
Description
***********
On a system with hybrid CPU cores, it is generally best to allow the OS to schedule threads across
all core types. However, advanced users may occasionally need to constrain the scheduling.
The ``constraints::set_core_type(core_type_id)`` API supports only a single core type, which may not allow selecting a suitable subset on processors with more than two core types.
The core type selector addresses this by allowing a callable object (*selector*) to rank every
available core type. The selector is called once for each core type returned by
``tbb::info::core_types()``. Positive scores indicate core types that should be used, negative
scores exclude core types, and a score of zero means "use only if multi-core-type constraints are
not supported" (see `Selector Requirements`_ for details).
This feature extends the :onetbb-spec:`tbb::task_arena <task_scheduler/task_arena/task_arena_cls>`
and the :onetbb-spec:`tbb::info <info_namespace>` specifications with the following API:
* Adds the ``selectable`` constant to ``task_arena``.
* Adds a new ``task_arena`` constructor template that accepts a ``constraints`` object together with
a selector.
* Adds a new ``task_arena::initialize`` template that accepts a ``constraints`` object together with
a selector.
* Adds a new ``info::default_concurrency`` template that returns the effective concurrency for given
map_typemap;// This object will use SharedMutexWrapper for thread safety of insert/find/erase operations
}
/*end_custom_mutex_chmap_example*/
#else // C++17
// Skip
intmain(){}
#endif
Loaded 100 of 1346 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Konstantin Boyarinov
