User avatar admin

Resource updated
File “doc/modules/ROOT/pages/concurrent_zh_Hans.adoc” was added. 06/05/2026
User avatar admin

String added in the repository
This interoperability comes handy in multistage scenarios where parts of the data processing happen in parallel whereas other steps are non-concurrent (or non-modifying). In the following example, we want to construct a histogram from a huge input vector of words: the population phase can be done in parallel with `boost::concurrent_flat_map` and results then transferred to the final container.
This interoperability comes handy in multistage scenarios where parts of the data processing happen in parallel whereas other steps are non-concurrent (or non-modifying). In the following example, we want to construct a histogram from a huge input vector of words: the population phase can be done in parallel with `boost::concurrent_flat_map` and results then transferred to the final container.
06/05/2026
User avatar admin

String added in the repository
^|`boost::concurrent_flat_map` ^|`boost::unordered_flat_map`
^|`boost::concurrent_flat_map` ^|`boost::unordered_flat_map`
06/05/2026
User avatar admin

String added in the repository
^|`boost::concurrent_flat_set` ^|`boost::unordered_flat_set`
^|`boost::concurrent_flat_set` ^|`boost::unordered_flat_set`
06/05/2026
User avatar admin

String added in the repository
^|`boost::concurrent_node_map` ^|`boost::unordered_node_map`
^|`boost::concurrent_node_map` ^|`boost::unordered_node_map`
06/05/2026
User avatar admin

String added in the repository
^|`boost::concurrent_node_set` ^|`boost::unordered_node_set`
^|`boost::concurrent_node_set` ^|`boost::unordered_node_set`
06/05/2026
User avatar admin

String added in the repository
As open-addressing and concurrent containers are based on the same internal data structure, they can be efficiently move-constructed from their non-concurrent counterpart, and vice versa.
As open-addressing and concurrent containers are based on the same internal data structure, they can be efficiently move-constructed from their non-concurrent counterpart, and vice versa.
06/05/2026
User avatar admin

String added in the repository
Interoperability with non-concurrent containers
Interoperability with non-concurrent containers
06/05/2026
User avatar admin

String added in the repository
Another blocking operation is _rehashing_, which happens explicitly via `rehash`/`reserve` or during insertion when the table's load hits `max_load()`. As with non-concurrent containers, reserving space in advance of bulk insertions will generally speed up the process.
Another blocking operation is _rehashing_, which happens explicitly via `rehash`/`reserve` or during insertion when the table's load hits `max_load()`. As with non-concurrent containers, reserving space in advance of bulk insertions will generally speed up the process.
06/05/2026
User avatar admin

String added in the repository
Concurrent containers can be copied, assigned, cleared and merged just like any other Boost.Unordered container. Unlike most other operations, these are _blocking_, that is, all other threads are prevented from accesing the tables involved while a copy, assignment, clear or merge operation is in progress. Blocking is taken care of automatically by the library and the user need not take any special precaution, but overall performance may be affected.
Concurrent containers can be copied, assigned, cleared and merged just like any other Boost.Unordered container. Unlike most other operations, these are _blocking_, that is, all other threads are prevented from accesing the tables involved while a copy, assignment, clear or merge operation is in progress. Blocking is taken care of automatically by the library and the user need not take any special precaution, but overall performance may be affected.
06/05/2026
User avatar admin

String added in the repository
Blocking Operations
Blocking Operations
06/05/2026
User avatar admin

String added in the repository
There's a latency/throughput tradeoff here: it will take longer for incoming keys to be processed (since they are buffered), but the number of processed keys per second is higher. `bulk_visit_size` is the recommended chunk size —smaller buffers may yield worse performance.
There's a latency/throughput tradeoff here: it will take longer for incoming keys to be processed (since they are buffered), but the number of processed keys per second is higher. `bulk_visit_size` is the recommended chunk size —smaller buffers may yield worse performance.
06/05/2026
User avatar admin

String added in the repository
This functionality is not provided for mere syntactic convenience, though: by processing all the keys at once, some internal optimizations can be applied that increase performance over the regular, one-at-a-time case (consult the xref:benchmarks.adoc#benchmarks_boostconcurrent_flatnode_map[benchmarks]). In fact, it may be beneficial to buffer incoming keys so that they can be bulk visited in chunks:
This functionality is not provided for mere syntactic convenience, though: by processing all the keys at once, some internal optimizations can be applied that increase performance over the regular, one-at-a-time case (consult the xref:benchmarks.adoc#benchmarks_boostconcurrent_flatnode_map[benchmarks]). In fact, it may be beneficial to buffer incoming keys so that they can be bulk visited in chunks:
06/05/2026
User avatar admin

String added in the repository
_Bulk visitation_ allows us to pass all the keys in one operation:
_Bulk visitation_ allows us to pass all the keys in one operation:
06/05/2026
User avatar admin

String added in the repository
Suppose you have an `std::array` of keys you want to look up for in a concurrent map:
Suppose you have an `std::array` of keys you want to look up for in a concurrent map:
06/05/2026
User avatar admin

String added in the repository
Bulk visitation
Bulk visitation
06/05/2026
User avatar admin

String added in the repository
`visit_while` and `erase_if` can also be parallelized. Note that, in order to increase efficiency, whole-table visitation operations do not block the table during execution: this implies that elements may be inserted, modified or erased by other threads during visitation. It is advisable not to assume too much about the exact global state of a concurrent container at any point in your program.
`visit_while` and `erase_if` can also be parallelized. Note that, in order to increase efficiency, whole-table visitation operations do not block the table during execution: this implies that elements may be inserted, modified or erased by other threads during visitation. It is advisable not to assume too much about the exact global state of a concurrent container at any point in your program.
06/05/2026
User avatar admin

String added in the repository
There is one last whole-table visitation operation, `erase_if`:
There is one last whole-table visitation operation, `erase_if`:
06/05/2026
User avatar admin

String added in the repository
Traversal can be interrupted midway:
Traversal can be interrupted midway:
06/05/2026
User avatar admin

String added in the repository
In C++17 compilers implementing standard parallel algorithms, whole-table visitation can be parallelized:
In C++17 compilers implementing standard parallel algorithms, whole-table visitation can be parallelized:
06/05/2026

Search