Since recent OpenBSD versions have removed syscall(2) interface, use
futex(2) wrapper that was also added along with the SYS_futex syscall.
Closes https://github.com/boostorg/atomic/pull/68.
As a result of dependent libraries dropping support for C++03, Boost.Atomic
is no longer able to support C++03 and now requires C++11 as a minimum.
Drop C++03 compilers from the CI and update docs accordingly. No code changes
at this time.
On FreeBSD and OpenBSD 32-bit x86 targets are configured to use 53-bit precision
for long double type. The value still uses 80 bits of storage, but the lowest
11 bits of mantissa are zero.
While at it, also added support for 24-bit precision, which can be configured
in x87. Though the platforms where this configuration is used by default are
not known.
Also, when possible, use predefined macros by gcc and compatible compilers and
avoid including standard library header for defining floating point limit macros.
Related to https://github.com/boostorg/atomic/issues/14.
Boost libraries that deprecate C++03 support (namely, Boost.Chrono) are not
used in Boost.Atomic implementation, but they are used in tests (indirectly
through Boost.Thread), which means it will become impossible to test
Boost.Atomic when the support is removed.
For seq_cst we must issue a memory fence, so in this case use
cmpxchg8b/cmpxchg16b.
Also, optimized 32-bit x86 code path to make the compiler pass the value
to and from the xmm register instead of hardcoding it in asm blocks.
When gcc predefined macros are not defined, use Boost.Predef (which also
checks macros defined in the system endian.h header) to detect endianness.
This may help with gcc impostor compilers that do not define built-in
endianness macros.
Closes https://github.com/boostorg/atomic/issues/59.
The new macro disables ulock-based implementation of waiting and notifying
operations on Darwin systems. This may be useful to comply with Apple
App Store requirements.
Closes https://github.com/boostorg/atomic/issues/55.
UWP does not support APIs related to dynamic symbol binding and dlls.
Disable runtime detection of WaitOnAddress & co. for that target. These
APIs should be enabled at compile time on Windows 8.
Fixes https://github.com/boostorg/atomic/issues/54.
Supposedly, Boost.Atomic docs were generated in the root doc directory
because they were built as part of the boostdoc target. The updated Jamfile
uses boostrelease target instead, which will hopefully move the docs
under libs/atomic/doc.
Also removed unused css and images copying - we have neither in the docs.
The logo image is not used in the docs, only in README.md.
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.
When targeting Windows 8, the always_has_native_wait_notify static constant
would be set to false even though the native implementation of waiting
and notifying operations through WaitOnAddress would always be used.
To fix this, moved direct WaitOnAddress & co. usage to public header. This
also requires users to link with synchronization.lib, which is done
automatically on compilers that support auto-linking.
The compiled library still implements runtime detection of WaitOnAddress,
even when building for Windows 8 and later. This allows user's code to
be later compiled for Windows 7 and older and still work. This code is
not used when user's code targets Windows 8 or later.
As part of this refactoring, renamed has_synchronization test and
related CMake variable to better communicate that we're testing for
a library.
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.
mfence is more expensive on most recent CPUs than a lock-prefixed instruction
on a dummy location, while the latter is sufficient to implement sequential
consistency on x86. Some performance test results are available here:
https://shipilev.net/blog/2014/on-the-fence-with-dependencies/
Also, for seq_cst stores in gcc_atomic backend, use an xchg instead of
mov+mfence, which are generated by gcc versions older than 10.1.
The machinery to detect mfence presence is still left intact just in case
if we need to use this instruction in the future.
Closes https://github.com/boostorg/atomic/issues/36.
The typedefs indicate the atomic object type for an unsigned/signed
integer that is lock-free and preferably has native support for waiting
and notifying operations.
The inter-process atomics have ipc_ prefixes: ipc_atomic, ipc_atomic_ref
and ipc_atomic_flag. These types are similar to their unprefixed counterparts
with the following distinctions:
- The operations are provided with an added precondition that is_lock_free()
returns true.
- All operations, including waiting/notifying operations, are address-free,
so the types are suitable for inter-process communication.
- The new has_native_wait_notify() operation and always_has_native_wait_notify
static constant allow to test if the target platform has native support for
address-free waiting/notifying operations. If it does not, a generic
implementation is used based on a busy wait.
- The new set of capability macros added. The macros are named
BOOST_ATOMIC_HAS_NATIVE_<T>_IPC_WAIT_NOTIFY and indicate whether address-free
waiting/notifying operations are supported natively for a given type.
Additionally, to unify interface and implementation of different components,
the has_native_wait_notify() operation and always_has_native_wait_notify
static constant were added to non-IPC atomic types as well. Added
BOOST_ATOMIC_HAS_NATIVE_<T>_WAIT_NOTIFY capability macros to indicate
native support for inter-thread waiting/notifying operations.
Also, added is_lock_free() and is_always_lock_free to atomic_flag.
This commit adds implementation, docs and tests.
The value() operation is useful with futexes, but should not be used for
anything else, basically.
The lack of support for types with padding bits is documented more prominently.
The docs do mention that `long double` on x86 is supported though.
Also, added description of the new tests added recently.
Related to https://github.com/boostorg/atomic/issues/34.
The user may define BOOST_ATOMIC_LOCK_POOL_SIZE_LOG2 macro to specify
binary logarithm of the size of the internal lock pool. The macro
only has effect when building Boost.Atomic.
The generic implementation is based on the lock pool. A list of condition
variables (or waiting futexes) is added per lock. Basically, the lock
pool serves as a global hash table, where each lock represents
a bucket and each wait state is an element. Every wait operation
allocates a wait state keyed on the pointer to the atomic object. Notify
operations look up the wait state by the atomic pointer and notify
the condition variable/futex. The corresponding lock needs to be acquired
to protect the wait state list during all wait/notify operations.
Backends not involving the lock pool are going to be added later.
The implementation of wait operation extends the C++20 definition in that
it returns the newly loaded value instead of void. This allows the caller
to avoid loading the value himself.
The waiting/notifying operations are not address-free. Address-free variants
will be added later.
Added tests for the new operations and refactored existing tests for atomic
operations. Added docs for the new operations.
The macro was used to highlight the (op)_and_test methods of atomic<>
that changed the returned value to the opposite in Boost 1.67. The old
behavior was only released in 1.66 and the macro was a means to help
1.66 users to transition to the new releases.
1.67 will have been released 2 years before the upcoming 1.73 release,
in which this macro will be removed.
We currently don't support structs with padding bits, so the checks
are useless. Also, updated docs so that users are not given the idea
that structs with padding bits are supported.
The support includes:
- The standard fetch_add/fetch_sub operations.
- Extra operations: (fetch_/opaque_)negate, (opaque_)add/sub.
- Extra capability macros: BOOST_ATOMIC_FLOAT/DOUBLE/LONG_DOUBLE_LOCK_FREE.
The atomic operations are currently implemented on top of the integer-based
backends and thus are mostly CAS-based. The CAS operations perform binary
comparisons, and as such have different behavior wrt. special FP values like
NaN and signed zero than normal C++.
The support for floating point types is optional and can be disabled by
defining BOOST_ATOMIC_NO_FLOATING_POINT. This can be useful if on a certain
platform parameters of the floating point types cannot be deduced from the
compiler-defined or system macros (in which case the compilation fails).
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0020r6.html
