boostorg/unordered
1
0
Fork 1
mirror of https://github.com/boostorg/unordered.git synced 2025-07-29 19:07:15 +02:00
Code Issues Packages Projects Releases Wiki 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
Concurrent member function invocations for the same instance of `Hash`, `Pred`, and `Allocator`
are required to not introduce data races (they must be thread-safe).
Concurrent invocations of `operator()` on the same const instance of `Hash` or `Pred` are required
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
`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
user-provided visitation function do not introduce data races when the visitation function
is executed internally by the `boost::concurrent_flat_map`. Visitation
functions executed by a `concurrent_flat_map` `x` are not allowed to invoke any operation
is executed internally by the `boost::concurrent_flat_map`.
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
if concurrent outstanding operations on `y` do not access `x` directly or indirectly.