feedc0de/boost_unordered
1
0
Fork 0
forked from boostorg/unordered
Code Pull Requests Activity

Feature/nonconst set visit (#265)

Browse Source 
* Made some boost::concurrent_flat_set operations exclusive-locked

* unnamed unused args

* fixed PR number

* replaced homemade mechanism with boost::compat::latch
This commit is contained in:
joaquintides
2024-07-16 19:50:08 +02:00
committed by GitHub
parent 7ddd562532
commit 1d1f0d306d
5 changed files with 251 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/unordered/concurrent_flat_map.adoc
+7 -3
View File
@@ -389,9 +389,13 @@ prior blocking operations on `x` synchronize with *op*. So, blocking operations
An operation is said to be _blocking on rehashing of_ ``__x__`` if it blocks on `x`
only when an internal rehashing is issued.
Access or modification of an element of a `boost::concurrent_flat_map` passed by reference to a
user-provided visitation function do not introduce data races when the visitation function
is executed internally by the `boost::concurrent_flat_map`.
When executed internally by a `boost::concurrent_flat_map`, the following operations by a
user-provided visitation function on the element passed do not introduce data races:
* Read access to the element.
* Non-mutable modification of the element.
* Mutable modification of the element (if the container operation executing the visitation function is not const
and its name does not contain `cvisit`.)
Any `boost::concurrent_flat_map operation` that inserts or modifies an element `e`
synchronizes with the internal invocation of a visitation function on `e`.