Explore new features and tools within Intel® products, communities, and platforms
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.
24 Discussions

oneTBB Concurrent Container Class: An Efficient Way To Scale Your C++ Application

1 0 3,766

Author: Nikita Sanjay Shiledarbaxi

Reviewer: Chandan Damannagari


Are you in search of an efficient way of scaling your C++ application in a concurrent environment? The Intel® oneAPI Threading Building Blocks library (Intel® oneTBB) can assist you in the best way, even if you are not a threading concepts’ expert. The thread-unsafe containers of the standard template library (STL) cannot work in concurrent environment and that is where oneTBB becomes advantageous. You can scale your application much faster using the thread-safe concurrent containers of this performant library.

Check out the webinar below in which Aleksei Fedotov explains the limitations of using STL containers for scalability and introduces a way better solution for parallelism i.e., concurrent container classes of the oneTBB library.


Before diving deeper into the concurrent container classes, let us have an overview of the Intel® oneTBB library.

What is Intel® oneTBB?

Intel® oneTBB, is one of the crucial component libraries of the Intel® oneAPI ecosystem for leveraging parallel programming paradigm. It enables adding parallelism to DPC++ and standard C++ applications across accelerated CPUs. It is supported by Windows, Linux, macOS, and Android operating systems. Some of the highlighting features of oneTBB include:

  • Support for functional and data parallelism. You only need to specify what parts of the algorithm can be processed in parallel. The runtime does the rest: allocate necessary number of threads, distribute the work onto allocated threads, and run the given algorithm(s) on them.
  • Efficient coordination of work between CPUs and accelerators such as GPUs.
  • Seamless compatibility with the conventional threading packages.

More details of Intel® oneTBB are available here. Download the stand-alone version of oneTBB or get it included as a part of the Intel® oneAPI Base Toolkit.

Now that you have a brief idea about oneTBB, let us come to the topic of containers.

What is a container?

A container in C++ is a data structure serving a specific purpose. It is an entity that stores objects and controls their allocation and deallocation. Each container has its own interface, semantics, memory consumption, and complexity of algorithms that can be run on a container. The standard template library (STL) commonly distributed with C++ compilers comes with several standard containers such as vector, list, and array associative ones such as ordered and unordered map, multimap, and set. Additionally, it has container adapters such as queue, priority queue, and stack whose user interface semantically differs from that of the actual underlying containers.

Watch the webinar from 0:03:02 to get a brief introduction on some popular STL containers.

Why oneTBB concurrent containers?

Consider a database application where multiple sources are attempting to access the same instance of a standard container, say an unordered map. Data races may occur when standard containers are used in concurrent environment as they are not thread safe. A possible solution to achieve thread-safety is to use a mutex – a shared object that allows only one thread at a time to access the shared memory. Using a single mutex faces a limitation that a single thread accessing the container acquires the lock for the whole container, making it inaccessible to the other threads even if they want to access a different container element. This significantly limits the scalability of such code.

In addition, increasing the number of threads degrades the application’s performance because of the cache coherency protocol – multiple threads attempt to read the shared memory from the same mutex object. Thus, in serial environment thread-unsafe standard containers may yield better performance than any thread-safe container because the former does not include synchronization overhead that any thread-safe container has. However, thread-unsafe containers cannot be used in concurrent environment. Here comes the need for concurrent containers.

How mutexes are employed for explicit thread synchronization and what limits the use of STL containers have been explained in the webinar from 0:10:40.

Concurrent containers in oneTBB

Concurrent containers of oneTBB include vectors, various queues, and associative containers such as maps and sets. The associative containers include ordered and unordered counterparts. The video, at 0:26:06, demonstrates building a histogram using concurrent hash map. To date oneTBB includes 13 fully supported containers and one container in a preview status*. The synchronization schemes used in oneTBB containers differ and range from fine-grained locking to completely lock-free algorithms.

* Preview status means the feature is fully working and of a good quality, but its support is not yet committed.

Interface difference

Where applicable, concurrent containers semantically resemble the corresponding STL containers. However, their interface differs from that of the STL counterparts in places where specifics of concurrent environment are required. Consider a standard C++ code in which you pop an element of a STL priority queue using a series of methods – empty() to check that the queue has at least one element, top() to get the topmost element and then pop() to update the queue. A thread performing these steps may get preempted in the middle of its work by some other thread and lose control over the container. Instead, concurrent queue from oneTBB employs a single method try_pop() to perform the whole task. Understand this example through a code snippet explained at 0:16:33 in the webinar.


oneTBB concurrent container class provides a flexible and efficient way of building scalable C++ applications with a high-level of concurrency. Get started with Intel® oneTBB for easy-to-handle yet efficient threading experience even in parallel programming. Aleksei Fedotov explains in the webinar how and why concurrent containers perform the STL containers that do not permit parallel updates in concurrent environment. Stay tuned and we will be back with more webinars on oneTBB and other oneAPI tools in the future. Check out the Intel® oneTBB library today - download it as a part of the Intel® oneAPI Base Toolkit or its stand-alone version.

Useful resources

Related webinars:


We would like to thank Aleksei Fedotov and Rob Mueller-Albrecht for their contributions to the blog.