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

refined concurrency requirements and guarantees

Browse Source
This commit is contained in:
joaquintides
2023-05-05 17:37:20 +02:00
parent 814264082f
commit 03fccc1947
1 changed files with 17 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
doc/unordered/concurrent_flat_map.adoc
View File

@ -327,8 +327,19 @@ at the expense of extra computational cost.
=== Concurrency requirements and guarantees === Concurrency requirements and guarantees
Concurrent member function invocations for the same instance of `Hash`, `Pred`, and `Allocator` Concurrent invocations of `operator()` on the same const instance of `Hash` or `Pred` are required
are required to not introduce data races (they must be thread-safe). to not introduce data races. For `Alloc` being either `Allocator` or any allocator type rebound
from `Allocator`, concurrent invocations of the following operations on the same instance `al` of `Alloc`
are required to not introduce data races:
* Copy construction from `al` of an allocator rebound from `Alloc`
* `std::allocator_traits<Alloc>::allocate`
* `std::allocator_traits<Alloc>::deallocate`
* `std::allocator_traits<Alloc>::construct`
* `std::allocator_traits<Alloc>::destruct`
In general, these requirements on `Hash`, `Pred` and `Allocator` are met if these types
are not stateful or if the operations only involve constant access to internal data members.
With the exception of destruction, concurrent invocations of any operation on the same instance of a With the exception of destruction, concurrent invocations of any operation on the same instance of a
`concurrent_flat_map` do not introduce data races — that is, they are thread-safe. `concurrent_flat_map` do not introduce data races — that is, they are thread-safe.
@ -342,8 +353,10 @@ only when an internal rehashing is issued.
Access or modification of an element of a `boost::concurrent_flat_map` passed by reference to a 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 user-provided visitation function do not introduce data races when the visitation function
is executed internally by the `boost::concurrent_flat_map`. Visitation is executed internally by the `boost::concurrent_flat_map`.
functions executed by a `concurrent_flat_map` `x` are not allowed to invoke any operation Any `boost::concurrent_flat_map operation` that inserts or modifies an element `e`
synchronizes with the internal invocation of a visitation function on `e`.
Visitation functions executed by a `boost::concurrent_flat_map` `x` are not allowed to invoke any operation
on `x`; invoking operations on a different `boost::concurrent_flat_map` instance `y` is allowed only on `x`; invoking operations on a different `boost::concurrent_flat_map` instance `y` is allowed only
if concurrent outstanding operations on `y` do not access `x` directly or indirectly. if concurrent outstanding operations on `y` do not access `x` directly or indirectly.