Added a missing import-search directive to config/Jamfile so that
atomic-arch-config.jam is found when configure-time checks are invoked
from tests. This allows us to enable the type_traits check for tests.
Added is_trivially_copyable and is_trivially_default_constructible type
traits that rely on the non-standard type traits available in libstdc++
from gcc 4.8 and 4.9.
Rather than requiring cxx11_hdr_type_traits in the library and test
requirements, use a more limited test that checks only the type traits
we use in Boost.Atomic.
Similarly, downgrade the requirement of C++ unrestricted unions to
unions with members that have non-trivial default constructors.
Remove the requirements of alignas and alignof, since those are not
mandatory for now.
Closes https://github.com/boostorg/atomic/issues/74.
This is a Boost.Atomic extension over std::atomic.
Bitwise operations can be useful if the enumeration is used to implement
a bit mask or a set of flags. Without these operations, users have to
manually perform conversions between the enum type and the underlying
type, which can be tedious.
There are caveats with enums with non-fixed underlying type, but the
convenience outweighs the potential pitfalls.
Occasionally, notify_one_test fails because the second thread receives
value2 instead of value3, even though the wakeup delay check passes.
This typically happens on one of the VM runners, so it is possible
there is some weird timing issue, when the thread gets woken up spuriously,
before the atomic value is updated, but the recorded wait time ends
up just above the expected waiting duration. Just retry the test
in this case.
Also use seq_cst in wait tests consistently instead of release on
stores and seq_cst on waits.
Replaced C++11 emulation macros with proper keywords, replaced typedefs
with using-style type aliases, removed type traits shims that are no
longer needed.
ARM64EC is similar to ARM64 in that the binary will run natively on
ARM64 CPUs and therefore supports all ARM64 intrinsics. The difference
is that it also supports AMD64 intrinsics (and therefore defines _M_AMD64
and _M_X64), which will be emulated by an implicitly linked library.
ARM64EC also changes ABI compared to ARM64, but it doesn't affect
Boost.Atomic.
Changed predefined macro checks in order to use msvc_arm backend for
ARM64EC instead of msvc_x86. The benefit is that msvc_arm uses memory
order-aware intrinsics instead of the full-fence ones on x86. The
downside is that 128-bit atomics won't be available (for now).
Also define BOOST_ATOMIC_DETAIL_INT_FP_ENDIAN_MATCH for ARM/ARM64
on Windows.
Although smt_pause matches the equivalent global function on Solaris and
some BSD systems both in name and behavior, this naming clash may cause
confusion and ambiguities in users' code that imports boost::atomics
namespace into their scope and calls smt_pause unqualified. Better
avoid these issues and pick a different name.
Add a simple test for thread_pause, which only tests that the operation
compiles and executes.
Also include the recently added headers in the global atomic.hpp.
This uses std::chrono::steady_clock universally in tests where monotonic
clock is needed. On Windows, hopefully this will resolve the time mismatches
between wakeups and externally measures times. Given that we use absolute
timeouts for sleeps, hopefully, this will also not reintroduce problems
that were originally worked around by test_clock.
We are going to use more C++11 features unconditionally, so add more
requirements in the build files. Don't straight require cxx11 in the
Jamfile as this eliminates all versions of MSVC from the builds.
Also remove older compilers that don't support enough of C++11 from CI.
This removes dependencies on Boost.Thread and Boost.Chrono, as well as
their dependencies and potentially allows to test more compilers. In particular,
this removes the dependency on Boost.Lexical cast, which no longer compiles
with gcc 4.6 and 4.7.
This is in line with the C++20 change that requires the default constructor
of std::atomic to value initialize the atomic object.
Also, use is_nothrow_default_constructible to properly deduce noexceptness
of the default constructors of atomics.
This allows to mark bitwise_cast constexpr when the conditions to use
bit_cast are met:
- both source and target types have the same size, and
- the source type has no padding bits.
The latter is checked using has_unique_object_representations trait, which
we also implement using intrinsics when not available in the standard
library.
This allows atomic constructors to become constexpr for structs and floating
point types with no padding and whose size matches the atomic storage size.
Use __builtin_clear_padding and __builtin_zero_non_value_bits that were
introduced in gcc 11 and MSVC 19.27 to clear the padding bits in atomic
types. The intrinsics are used in bitwise_cast and atomic reference
constructors.
Also, separated atomic impl specializations for enums to allow using
static_cast to convert values to storage. This in turn allows to
relax compiler requirements to mark atomic constructors constexpr.
Updated docs and added tests for structs with padding and constexpr
atomic constructors.
This works around spurious test failures on Mac OS as the notifying operation
sometimes fails with ENOENT. Presumably, the OS sometimes invalidates the
internal identification of the stack memory region, which makes __ulock_wake
fail to find the ulock object that other threads are blocked on.
By using dynamic memory we (hopefully) are using a location in a normal mapped
memory region that should not be mangled by the OS. Ideally, we would use
process-shared memory for this test, but that makes it more difficult to make
it portable and runnable in parallel. Dynamic local memory should do for now.
This test verifies arithmetic and bitwise (logic) operations with
immediate constant arguments, which may affect instruction choice
in the operations. In particular, the test verifies that bug
https://github.com/boostorg/atomic/issues/41 is fixed.
This is the second iteration of the backends, which were both tested
on a QEMU VM and did not show any test failures. The essential difference
from the first version is that in AArch64 we now initialize the success flag
in the asm blocks in compare_exchange operations rather than relying on
compiler initializing it before passing into the asm block as an in-out
parameter. Apparently, this sometimes didn't work for some reason, which
made compare_exchange_strong return incorrect value, which broke futex-based
mutexes in the lock pool.
The above change was also applied to AArch32, along with minor corrections
in the asm blocks constraints.
We need to explicitly link with synchronization.lib when the
WaitOnAddress API is enabled at compile time for ARM targets. Since
this library is only available on newer Windows SDKs, we have to perform
a configure check for whether it is available.
The old operations template is replaced with core_operations, which falls
back to core_arch_operations, which falls back to core_operations_emulated.
The core_operations layer is intended for more or less architecture-neutral
backends, like the one based on gcc __atomic* intrinsics. It may fall back
to core_arch_operations where it is not supported by the compiler or where
the latter is more optimal. For example, where gcc does not implement 128-bit
atomic operations via __atomic* intrinsics, we support them in the
core_arch_operations backend, which uses inline assembler blocks.
The old emulated_operations template is largely unchanged and was renamed to
core_operations_emulated for naming consistency. All other operation templates
were also renamed for consistency (e.g. generic_wait_operations ->
wait_operations_generic).
Fence operations have been extracted to a separate set of structures:
fence_operations, fence_arch_opereations and fence_operations_emulated. These
are similar to the core operations described above. This structuring also
allows to fall back from fence_operations to fence_arch_opereations when
the latter is more optimal.
The net result of these changes is that 128-bit and 64-bit atomic operations
should now be consistently supported on all architectures that support them.
Previously, only x86 was supported via local hacks for gcc and clang.
The backend implements core and extra atomic operations using gcc asm blocks.
The implementation supports extensions added in ARMv8.1 and ARMv8.3. It supports
both little and big endian targets.
Currently, the code has not been tested on real hardware. It has been tested
on a QEMU VM.
The previous change to increase the delay didn't help, so we're instead
changing the expectation - the first woken thread is allowed to receive
value3 on wake up.
Occasionally, IPC notify_one test fails on Windows because the first
of the woken threads receives value3 from wait(). This is possible if
the thread lingers in wait() for some reason. Increase the delay
before the second notification slightly to reduce the likelihood
of this happening.
The implementation uses GetTickCount/GetTickCount64 internally,
which is a steady and sufficiently low precision time source.
We need the clock to have relatively low precision so that wait
tests don't fail spuriously because the blocked threads wake up
too soon, according to more precise clocks.
boost::chrono::system_clock currently has an acceptably low precision,
but it is not a steady clock.
Checking for the capability macros is not good enough because ipc_atomic_ref
can be not lock-free even when the macro (and ipc_atomic) indicates lock-free.
We now check the is_always_lockfree property to decide whether to run or skip
tests for a given IPC atomic type.
Also, made struct_3_bytes output more informative.
