Exit Zen
12
:116
English
Visitation is prominent in the API provided by concurrent containers, and many classical operations have visitation-enabled variations:
42/1350 · 135
13
:128
English
Note that in this last example the visitation function could actually _modify_ the element: as a general rule, operations on a concurrent map `m` will grant visitation functions const/non-const access to the element depending on whether `m` is const/non-const. Const access can be always be explicitly requested by using `cvisit` overloads (for instance, `insert_or_cvisit`) and may result in higher parallelization. For concurrent sets, on the other hand, visitation is always const access.
161/4920 · 492
14
:136
English
Although expected to be used much less frequently, concurrent containers also provide insertion operations where an element can be visited right after element creation (in addition to the usual visitation when an equivalent element already exists):
56/2480 · 248
15
:152
English
Consult the references of `xref:reference/concurrent_node_set.adoc#concurrent_node_set[boost::concurrent_node_set]`, `xref:reference/concurrent_node_map.adoc#concurrent_node_map[boost::concurrent_node_map]`, `xref:reference/concurrent_flat_set.adoc#concurrent_flat_set[boost::concurrent_flat_set]` and `xref:reference/concurrent_flat_map.adoc#concurrent_flat_map[boost::concurrent_flat_map]` for the complete list of visitation-enabled operations.
421/4470 · 447
16
:159
English
Whole-Table Visitation
4/220 · 22
17
:161
English
In the absence of iterators, `visit_all` is provided as an alternative way to process all the elements in the container:
45/1200 · 120
18
:171
English
In C++17 compilers implementing standard parallel algorithms, whole-table visitation can be parallelized:
47/1050 · 105
19
:181
English
Traversal can be interrupted midway:
10/360 · 36
20
:202
English
There is one last whole-table visitation operation, `erase_if`:
28/630 · 63
21
:211
English
`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.
144/3960 · 396
22
:217
English
Bulk visitation
4/150 · 15
23
:219
English
Suppose you have an `std::array` of keys you want to look up for in a concurrent map:
35/850 · 85
24
:230
English
_Bulk visitation_ allows us to pass all the keys in one operation:
24/660 · 66
25
:237
English
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:
147/4020 · 402
26
:261
English
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.
102/2730 · 273
27
:266
English
Blocking Operations
5/190 · 19
28
:268
English
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.
128/4530 · 453
29
:274
English
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.
117/2690 · 269
30
:278
English
Interoperability with non-concurrent containers
11/470 · 47
31
:280
English
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.
57/1870 · 187