History log of /oneTBB/src/tbb/concurrent_monitor.h (Results 1 – 9 of 9)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v2021.12.0-rc1, v2021.4.1, v2021.11.0, v2021.2.4, v2021.11.0-rc1
# e1310717 11-Sep-2023 Dmitri Mokhov <[email protected]>

Fix/suppress new GCC 12/13 warnings (#1192)

Signed-off-by: Dmitri Mokhov <[email protected]>


Revision tags: v2021.11.0-src-rc1, v2021.2.3, v2021.10.0, v2021.10.0-rc1, v2020.3.3, v2021.2.2, v2021.9.0, v2021.2.1, v2021.9.0-rc1, v2020.3.2, v2021.8.0, v2021.8.0-rc1, v2020.3.1, v2021.7.0, v2021.7.0-rc1, v2021.6.0, v2021.6.0-rc1
# 8a874694 22-Dec-2021 Andrey Semashev <[email protected]>

Optimize x86 atomic_fence (#328)

* Added optimized x86 atomic_fence for gcc-compatible compilers.

On x86 (32 and 64-bit) any lock-prefixed instruction provides sequential
consistency guarantees

Optimize x86 atomic_fence (#328)

* Added optimized x86 atomic_fence for gcc-compatible compilers.

On x86 (32 and 64-bit) any lock-prefixed instruction provides sequential
consistency guarantees for atomic operations and is more efficient than
mfence.

We are choosing a "lock not" on a dummy byte on the stack for the following
reasons:

- The "not" instruction does not affect flags or clobber any registers.
The memory operand is presumably accessible through esp/rsp.
- The dummy byte variable is at the top of the stack, which is likely
hot in cache.
- The dummy variable does not alias any other data on the stack, which
means the "lock not" instruction won't introduce any false data
dependencies with prior or following instructions.

In order to avoid various sanitizers and valgrind complaining, we have to
initialize the dummy variable to zero prior to the operation.

Additionally, for memory orders weaker than seq_cst there is no need for
any special instructions, and we only need a compiler fence. For the relaxed
memory order we don't need even that.

This optimization is only enabled for gcc up to version 11. In gcc 11 the
compiler implements a similar optimization for std::atomic_thread_fence.
Compilers compatible with gcc (namely, clang up to 13 and icc up to 2021.3.0,
inclusively) identify themselves as gcc < 11 and also benefit from this
optimization, as they otherwise generate mfence for
std::atomic_thread_fence(std::memory_order_seq_cst).

Signed-off-by: Andrey Semashev <[email protected]>

* Removed explicit mfence in atomic_fence on Windows.

The necessary instructions according to the memory order argument
should already be generated by std::atomic_thread_fence.

Signed-off-by: Andrey Semashev <[email protected]>

* Removed memory order argument from atomic_fence.

The code uses memory_order_seq_cst in all call sites of atomic_fence,
so remove the argument and simplifiy the implementation a bit. Also, renamed
the function to make the memory order it implements apparent.

Signed-off-by: Andrey Semashev <[email protected]>

show more ...


Revision tags: v2021.5.0
# ba947f18 21-Oct-2021 Ilya Isaev <[email protected]>

Changes in code after applying some clang-tidy check fixes (#620)

Applied fixes from clang-tidy(readability and modernize)

Signed-off-by: Ilya Isaev [email protected]


Revision tags: v2021.5.0-rc2, v2021.5.0-rc1, v2021.4.0, v2021.4.0-rc1, v2021.3.0
# 478de5b1 05-May-2021 tbbdev <[email protected]>

Commit oneTBB source code 82ff8707


# 4523a761 01-Mar-2021 tbbdev <[email protected]>

Commit oneTBB source code 4fcd448a


Revision tags: v2021.2.0, v2021.2.0-rc
# b15aabb3 26-Jan-2021 tbbdev <[email protected]>

Commit oneTBB source code 9ed4a21c


Revision tags: v2021.1.1
# 8dcbd5b1 18-Nov-2020 tbbdev <[email protected]>

Commit oneTBB source code 8fda6294


# 49e08aac 28-Oct-2020 tbbdev <[email protected]>

Commit oneTBB source code 6420d97a


Revision tags: v2021.1-beta10
# 51c0b2f7 25-Sep-2020 tbbdev <[email protected]>

Commit oneTBB source code 4ebd2d06