BOOST_ATOMIC_NO_DARWIN_ULOCKconfiguration macro. The macto affects compilation on Darwin systems and disables
ulock-based implementation of waiting and notifying operations. This may be useful to comply with Apple App Store requirements. (GH#55)
SYS_futex_time64syscall, such as riscv32.
std::alignment_ofon clang 8 for 64-bit types on 32-bit x86 targets.
atomic-type::always_has_native_wait_notifyand the corresponding capability macros when targeting Windows 8 or later. The library will now directly use
WaitOnAddressand related APIs from public headers and therefore require user to link with
synchronization.libif the user requires Windows 8 or later by defining
_WIN32_WINNTor similar macros. The library is linked automatically on compilers that support auto-linking (e.g. MSVC).
long doubleon x86 targets. A new
BOOST_ATOMIC_NO_CLEAR_PADDINGcapability macro is defined to indicate when clearing the padding is not supported.
ipc_atomic_refno longer use atomic instructions to clear the padding bits in the referenced object. This reduces the cost of the atomic reference construction. This is considered safe because clearing the padding does not issue writes to the bytes that contribute to the object value. However, some thread safety checking software may falsely detect this as a data race.
constexprfor enums, classes and floating point types. For classes and floating point types, the constructors are
constexprif the compiler supports
std::bit_cast, the type has no padding bytes and no padding is required to implement native atomic operations (i.e., for
atomic<T>, the object of type
Tfits exactly in the internal storage of the atomic).
ipc_atomicnow perform value initialization of the contained object. For types without a user-defined default constructor, this means the default-constructed atomic will be zero-initialized.
make_ipc_atomic_reffactory functions for constructing atomic reference objects.
ipc_atomic_refto allow omitting template arguments when they can be deduced from constructor arguments.
constqualifiers to some operations in
yieldinstruction on ARMv8-A. The instruction is used internally in spin loops to reduce CPU power consumption.
has_native_wait_notify, a static boolean constant
always_has_native_wait_notifyand a set of capability macros that allow to detect if the implementation supports native waiting and notifying operations for a given type.
atomic_flagto use 32-bit storage. This allows for more efficient waiting and notifying operations on
atomic_flagon some platforms.
BOOST_ATOMIC_LOCK_POOL_SIZE_LOG2macro to specify binary logarithm of the size of the lock pool. The default value is 8, meaning that the size of the lock pool is 256, up from 64 used in the previous release.
ipc_atomic_ref. Users are recommended to port their code using non-IPC types for inter-process communication to the new types. The new types provide the same set of operations as their non-IPC counterparts, with the following differences:
truefor the given atomic object. The library will issue a compile time error if this precondition is known to be not satisfied at compile time.
ipc_atomic_ref- the referenced object) may be located in process-shared memory or mapped into the same process at multiple different addresses.
always_has_native_wait_notifyconstant indicate support for native inter-process waiting and notifying operations. When that support is not present, the operations are implemented with a busy loop, which is less efficient, but still is address-free. A separate set of capability macros is also provided to indicate this support.
atomic_signed_lock_freetypes introduced in C++20. The types indicate the atomic object type for an unsigned or signed integer, respectively, that is lock-free and preferably has native support for waiting and notifying operations.
lock-prefixed instructions instead of
mfence. This means that the operations no longer affect non-temporal stores, which was also not guaranteed before. Use specialized instructions and intrinsics to order non-temporal memory accesses.
long doubleon x86 targets not indicating lock-free operations even if 128-bit atomic operations were available.
__sync*intrinsics backend, fixed that store and load operations of large objects (larger than a pointer size) could be non-atomic. The implementation currently assumes that small objects can be stored with a single instruction atomically on all modern architectures.
atomic_ref. See docs and especially the caveats section.
atomic_flag::testoperation, which was introduced in C++20.
atomic<T>should now take into account alignment requirements of
T, which makes a difference if those requirements are higher than that of the internal storage of
atomic_ref. This should prohibit invalid types from being used as atomics.
bit_test_and_*operations on 8 and 16-bit arguments. Other architectures are not affected.
compare_exchange_*operations, if alignment requirements of
value_typeare less than that of the internal storage of
boost/atomic/atomic.hppno longer includes
boost/atomic/fences.hppand only defines the
boost::atomicclass template and related typedefs. Include the other headers explicitly or use
boost/atomic.hppto include all parts of Boost.Atomic.
atomic<T>::storage()accessor and associated
atomic<T>::storage_typetype are deprecated. Instead, users are advised to use
atomic<T>::value_type, respectively. Users can define
BOOST_ATOMIC_SILENCE_STORAGE_DEPRECATIONto disable deprecation warnings for the time of transition. The deprecated pieces will be removed in a future release.
BOOST_ATOMIC_DETAIL_HIGHLIGHT_OP_AND_TEST. This macro was used as a helper for transition to the updated returned values of
*_and_testoperations in Boost.Atomic 1.67, which was released 2 years before 1.73.
__float128not being considered as a floating point type by some versions of libstdc++.
(op)_and_testoperations added in Boost 1.66 to the opposite - the functions now return
trueif the operation result is non-zero. This is consistent with other
testmethods in Boost.Atomic and the C++ standard library. Users can define
BOOST_ATOMIC_DETAIL_HIGHLIGHT_OP_AND_TESTwhen compiling their code to emit warnings on every use of the changed functions. This way users can locate the code that needs to be updated. (GH#11)
memory_orderenumeration is now scoped and contains constants with shorter names like
seq_cst(i.e. users can use
memory_order_acquire). The old constants are also provided for backward compatibility. (P0439R0)
negateoperations and their
opaque_(op)versions are supported. Lock-free property can be tested with the new macros
BOOST_ATOMIC_FLOAT/DOUBLE/LONG_DOUBLE_LOCK_FREE. The support for floating point types is optional and can be disabled by defining
complement_and_testwhich perform negation or bitwise complement and return
trueif the result is not zero.
bitwise_complementoperations which perform the operation and return its result.
atomic<T>specialization, the default constructor is now trivial if
T's default constructor is.
atomic<T>has been updated to avoid undefined behavior that stems from signed integer overflows. As required by the C++ standard, the library uses two's complement representation of signed integers internally and accroding rules of overflow. Currently, the library requires the native signed integer types to also use two's complement representation (but no defined overflow semantics).
fetch_complement- atomically replaces the value with a negated or binary complemented value and returns the original value
opaque_<op>- equivalent to
fetch_<op>except that it doesn't return the original value
<op>_and_test- atomically applies
trueif the result is zero. Note: The result of these operations will change to the opposite in Boost 1.67. The code that uses these functions will need to be updated.
bit_test_and_complement- atomically sets, resets or complements the specified bit and returns the original value of the bit
atomic<T>::difference_typemember typedefs, where applicable, to the user's code.
atomic<T>::is_always_lock_freefor conformance with C++17. The constant indicates that the given specialization always provides lock-free implementation of atomic operations.
atomic<>storage. This should fix possible issues on platforms that support atomic operations on data units larger than the native word size. This may also change binary layout of user's data structures that have
memory_orderenumeration. The concrete values are not part of the interface, but this change may potentially break ABI, if the enum is used in user's interfaces.
cmpxchg16binstruction in the target CPUs. Some early AMD CPUs don't support this instruction. To target those define the
BOOST_ATOMIC_FLAG_INITmacro and static initialization of
atomic<>based on GCC
__atomic*intrinsics available since GCC 4.7.