2. Boost Unordered Translation (zh_Hans)
3. Doc / Modules / Root / Pages / Concurrent (adoc)
4. English
5. Zen

6 :47
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first thing a new user of Boost.Unordered concurrent containers will notice is that these classes _do not provide iterators_ (which makes them technically not https://en.cppreference.com/w/cpp/named_req/Container[Containers^] in the C++ standard sense). The reason for this is that iterators are inherently thread-unsafe. Consider this hypothetical code: 358/10000 · 358
7 :61
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In a multithreaded scenario, the iterator `it` may be invalid at point B if some other thread issues an `m.erase(k)` operation between A and B. There are designs that can remedy this by making iterators lock the element they point to, but this approach lends itself to high contention and can easily produce deadlocks in a program. `operator[]` has similar concurrency issues, and is not provided by `boost::concurrent_flat_map`/`boost::concurrent_node_map` either. Instead, element access is done through so-called _visitation functions_: 539/10000 · 539
8 :76
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The visitation function passed by the user (in this case, a lambda function) is executed internally by Boost.Unordered in a thread-safe manner, so it can access the element without worrying about other threads interfering in the process. 237/10000 · 237
9 :81
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — On the other hand, a visitation function can _not_ access the container itself: 79/10000 · 79
10 :90
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Access to a different container is allowed, though: 51/10000 · 51
11 :101
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — But, in general, visitation functions should be as lightweight as possible to reduce contention and increase parallelization. In some cases, moving heavy work outside of visitation may be beneficial: 199/10000 · 199
12 :116
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Visitation is prominent in the API provided by concurrent containers, and many classical operations have visitation-enabled variations: 135/10000 · 135
13 :128
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 492/10000 · 492
14 :136
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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): 248/10000 · 248
15 :152
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 447/10000 · 447
16 :159
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Whole-Table Visitation 22/10000 · 22
17 :161
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In the absence of iterators, `visit_all` is provided as an alternative way to process all the elements in the container: 120/10000 · 120
18 :171
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In C++17 compilers implementing standard parallel algorithms, whole-table visitation can be parallelized: 105/10000 · 105
19 :181
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Traversal can be interrupted midway: 36/10000 · 36
20 :202
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — There is one last whole-table visitation operation, `erase_if`: 63/10000 · 63
21 :211
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `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. 396/10000 · 396
22 :217
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Bulk visitation 15/10000 · 15
23 :219
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Suppose you have an `std::array` of keys you want to look up for in a concurrent map: 85/10000 · 85
24 :230
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — _Bulk visitation_ allows us to pass all the keys in one operation: 66/10000 · 66
25 :237
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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: 402/10000 · 402