documented concurrent/unordered interop

doc/unordered/concurrent.adoc

@@ -201,3 +201,29 @@ and the user need not take any special precaution, but overall performance may b
 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.
+
+== Interoperability with non-concurrent containers
+
+As their internal data structure is basically the same, `boost::unordered_flat_map` can
+be efficiently move-constructed from `boost::concurrent_flat_map` and vice versa.
+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.
+
+[source,c++]
+----
+std::vector<std::string> words = ...;
+
+// Insert words in parallel
+boost::concurrent_flat_map<std::string_view, std::size_t> m0;
+std::for_each(
+  std::execution::par, words.begin(), words.end(),
+  [&](const auto& word) {
+    m0.try_emplace_or_visit(word, 1, [](auto& x) { ++x.second; });
+  });
+
+// Transfer to a regular unordered_flat_map
+boost::unordered_flat_map m=std::move(m0);
+----