Git Product home page Git Product logo

atomic's Introduction

Boost.Atomic

Boost.Atomic, part of collection of the Boost C++ Libraries, implements atomic operations for various CPU architectures, reflecting and extending the standard interface defined in C++11 and later.

Directories

  • build - Boost.Atomic build scripts
  • doc - QuickBook documentation sources
  • include - Interface headers of Boost.Atomic
  • src - Compilable source code of Boost.Atomic
  • test - Boost.Atomic unit tests

More information

Build status

Branch GitHub Actions AppVeyor Test Matrix Dependencies
master GitHub Actions AppVeyor Tests Dependencies
develop GitHub Actions AppVeyor Tests Dependencies

License

Distributed under the Boost Software License, Version 1.0.

atomic's People

Contributors

bazald avatar caleridas avatar danieljames avatar douggregor avatar eldiener avatar flamefire avatar grafikrobot avatar hkaiser avatar jeremy-murphy avatar jhunold avatar juliekoubova avatar k-ballo avatar lastique avatar mike-devel avatar pdimov avatar steveire avatar timblechmann avatar viboes avatar xiejiss avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

atomic's Issues

Boost Atomic 1.78 breaks macOS/iOS integration

This recent change in Atomic

'Added a ulock backend for waiting and notifying operations on Darwin systems since Mac OS 10.12, iOS 10.0, tvOS 10.0 or watchOS 3.0'

Pretty much breaks all projects using Boost libraries that in turn depend on Atomic.
In our scenario we're using Boost Log on iOS/iPadOS and can no further submit updates to the App Store due to this change;
The *ulock functions are considered private API, thus automated checks detect the methods (doesn't matter if they're referenced or defined as a duplicate by Atomic) and any apps using Atomic are rejected ('Invalid Binary')

Travis configurations can be collapsed for efficiency

If you use cxxstd=03 instead of -std=c++03, this would allow testing of more than one cxxstd level in one go, f.ex. cxxstd=03,11,14,1z.

In addition, address-model=32,64 is also possible.

This avoids the common setup phase duplication and is therefore more efficient.

Cross compiling boost_1_56_0 compilation error in atomic lib

Hi Sir,
I am getting the following compilation error, while cross compiling boost_1_56_0 for raspberry pi.
However this error is not there in the boost_1_57_0.
But I donot have the luxury to upgrade to the newer version.
Could you please let me know how to fix this error on boost_1_56_0 its self.

Following are the compilation errors:

_"/home/centos/casoc-toolchain/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/arm-linux-gnueabihf-g++"  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC -pthread -fPIC  -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_ATOMIC_SOURCE -DNDEBUG  -I"." -c -o "bin.v2/libs/atomic/build/gcc-any/release/threading-multi/lockpool.o" "libs/atomic/src/lockpool.cpp"

libs/atomic/src/lockpool.cpp: In static member function 'static void boost::atomics::detail::lockpool::thread_fence()':
libs/atomic/src/lockpool.cpp:127:5: error: 'thread_fence' is not a member of 'boost::atomics::detail'
atomics::detail::thread_fence(memory_order_seq_cst);
^
libs/atomic/src/lockpool.cpp: In static member function 'static void boost::atomics::detail::lockpool::signal_fence()':
libs/atomic/src/lockpool.cpp:138:5: error: 'signal_fence' is not a member of 'boost::atomics::detail'
atomics::detail::signal_fence(memory_order_seq_cst);
^
...skipped <pbin.v2/libs/atomic/build/gcc-any/release/threading-multi>libboost_atomic.so.1.56.0 for lack of <pbin.v2/libs/atomic/build/gcc-any/release/threading-multi>lockpool.o...
...skipped <pstage/lib>libboost_atomic.so.1.56.0 for lack of <pbin.v2/libs/atomic/build/gcc-any/release/threading-multi>libboost_atomic.so.1.56.0...
...skipped <pstage/lib>libboost_atomic.so for lack of <pstage/lib>libboost_atomic.so.1.56.0...
common.mkdir bin.v2/libs/system/build/gcc-any/release_

Following are the 4 steps followed:

1)Download the cross compiler using: "git clone git://github.com/raspberrypi/tools.git"

2)Inside boost folder run:
./bootstrap.sh

3)Add the below line to project-config.jam
using gcc : any : /home/centos/rpi-toolchain-downloaded/tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ : -fPIC ;

4)Compiled it using:
./bjam -a -d+2

Thanks in advance,
Santhosh

Consider removing the AARCH64 128 bit atomic implementation (LDXP+STXP loop)

Using an LDXP+STXP loop for 128 bit atomics on ARM has multiple (IMO significant) downsides - at least when combined with the claim BOOST_ATOMIC_INT128_LOCK_FREE == 2.

  1. Loads cause a write. While this write is guaranteed to never change the value, it's still a write and thus may be problematic in e.g. shared memory scenarios where one of the processes has the memory mapped as read-only.

  2. Loads cause the cache line to be invalidated for all other cores. At least for me, when I write code that uses atomics, I expect an atomic load to have negligible impact on other threads access the same variable. I certainly don't expect the atomic load to invalidate the cache line for all other participants.

  3. Plain loads and stores both have to use a retry loop which means they can potentially take a very long time. IMO also unexpected and undesirable.

Personally I'd do one of the following:

  • Keep the implementation but make it opt-in via some #define the user must set (preferred)
  • Keep the implementation but make it opt-out via some #define the user can set
  • Keep the implementation but don't claim BOOST_ATOMIC_INT128_LOCK_FREE == 2

I'm aware that using the emulation via the lock pool has even more downsides. My main concern is that with the current implementation, it looks like there's a "normal", unproblematic hardware implementation for 128 bit atomics, when this hardware implementation does have some IMO significant and unexpected downsides.

For context: we're currently using Boost.Atomic without linking against the library. This means everything that would require emulation automatically fails to link. We want this, because it means we can use atomics without having to consider the implications of emulated atomics. Atomics just are ... atomic :)
Having the LDXP+STXP loop implementation on AARCH64 somewhat muddles the waters there.

Boost Log fails to build (MSVC, ARM64)

Hi, I might be doing something stupid, but my app fails to build for ARM64 when using Boost Log. The problem is in the core_arch_ops_msvc_arm.hpp header in all the places where the derived class tries to call the cas_common_order method from the base class. That method fails to resolve because the base class is a template:

...\vcpkg_installed\ARM64-windows\include\boost\atomic\detail\core_arch_ops_msvc_arm.hpp(225,17): error C3861: 'cas_common_order': identifier not found
...\vcpkg_installed\ARM64-windows\include\boost\atomic\detail\core_arch_ops_msvc_arm.hpp(225,33): message : 'cas_common_order': function declaration must be available as none of the arguments depend on a template parameter
...\vcpkg_installed\ARM64-windows\include\boost\atomic\detail\core_arch_ops_msvc_arm.hpp(316): message : see reference to class template instantiation 'boost::atomics::detail::core_arch_operations<1,Signed,Interprocess>' being compiled

Build failure on nios2 architecture

Since version 1.74.0, boost fails to build on nios2:

In file included from libs/atomic/src/lock_pool.cpp:29:
libs/atomic/src/lock_pool.cpp:1029:25: error: static assertion failed: Boost.Atomic unsupported target platform: native atomic operations not implemented for bytes
 BOOST_STATIC_ASSERT_MSG(once_flag_operations::is_always_lock_free, "Boost.Atomic unsupported target platform: native atomic operations not implemented for bytes");
                         ^~~~~~~~~~~~~~~~~~~~

Full build log is available here:
http://autobuild.buildroot.org/results/c03/c03a786791e3aa7801cf1bff9934c4a105f54ce1/build-end.log

Build error cross compiling 1.68.0 log for ARM

I'm attempting to cross compile v1.68 for ARM on Ubuntu (Cosmic), based on checking out that version of the code. I am unable to build some of the libraries I need. For example, I need boost log, but this fails to build.

I've set the compiler up in project.config.jam...

if ! gcc in [ feature.values ]
{
using gcc : arm : /usr/bin/aarch64-linux-gnu-g++ ;
}

Running /b2 as follows gives errors:
./b2 install -a toolset=gcc-arm architecture=arm abi=aapcs address-model=64 --prefix=/opt/cross/boost --with-log

....

gcc.compile.c++ bin.v2/libs/atomic/build/gcc-arm/release/threading-multi/lockpool.o
In file included from ./boost/atomic/detail/operations_lockfree.hpp:21:0,
                 from libs/atomic/src/lockpool.cpp:22:
/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:217:74: error: wrong number of template arguments (2, should be 1)
     public gcc_atomic_operations< typename make_storage_type< 8u, Signed >::type >
                                                                          ^
In file included from /usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:19:0,
                 from ./boost/atomic/detail/operations_lockfree.hpp:21,
                 from libs/atomic/src/lockpool.cpp:22:
./boost/atomic/detail/storage_type.hpp:66:8: note: provided for ‘template<long unsigned int Size> struct boost::atomics::detail::make_storage_type’
 struct make_storage_type
        ^
In file included from ./boost/atomic/detail/operations_lockfree.hpp:21:0,
                 from libs/atomic/src/lockpool.cpp:22:
/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:217:82: error: template argument 1 is invalid
     public gcc_atomic_operations< typename make_storage_type< 8u, Signed >::type >
                                                                                  ^
/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:218:1: error: expected ‘::’ before ‘{’ token
 {
 ^
/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:218:1: error: expected class-name before ‘{’ token
/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:255:74: error: wrong number of template arguments (2, should be 1)
     public gcc_atomic_operations< typename make_storage_type< 4u, Signed >::type >
                                                                          ^
In file included from /usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:19:0,
                 from ./boost/atomic/detail/operations_lockfree.hpp:21,
                 from libs/atomic/src/lockpool.cpp:22:
./boost/atomic/detail/storage_type.hpp:66:8: note: provided for ‘template<long unsigned int Size> struct boost::atomics::detail::make_storage_type’
 struct make_storage_type
        ^
In file included from ./boost/atomic/detail/operations_lockfree.hpp:21:0,
                 from libs/atomic/src/lockpool.cpp:22:
/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:255:82: error: template argument 1 is invalid
     public gcc_atomic_operations< typename make_storage_type< 4u, Signed >::type >
                                                                                  ^
/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:256:1: error: expected ‘::’ before ‘{’ token
 {
 ^
/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:256:1: error: expected class-name before ‘{’ token
/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:301:74: error: wrong number of template arguments (2, should be 1)
     public gcc_atomic_operations< typename make_storage_type< 2u, Signed >::type >
                                                                          ^
In file included from /usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:19:0,
                 from ./boost/atomic/detail/operations_lockfree.hpp:21,
                 from libs/atomic/src/lockpool.cpp:22:
./boost/atomic/detail/storage_type.hpp:66:8: note: provided for ‘template<long unsigned int Size> struct boost::atomics::detail::make_storage_type’
 struct make_storage_type
        ^
In file included from ./boost/atomic/detail/operations_lockfree.hpp:21:0,
                 from libs/atomic/src/lockpool.cpp:22:
/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:301:82: error: template argument 1 is invalid
     public gcc_atomic_operations< typename make_storage_type< 2u, Signed >::type >
                                                                                  ^
/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:302:1: error: expected ‘::’ before ‘{’ token
 {
 ^
/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:302:1: error: expected class-name before ‘{’ token
/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:355:74: error: wrong number of template arguments (2, should be 1)
     public gcc_atomic_operations< typename make_storage_type< 1u, Signed >::type >
                                                                          ^
In file included from /usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:19:0,
                 from ./boost/atomic/detail/operations_lockfree.hpp:21,
                 from libs/atomic/src/lockpool.cpp:22:
./boost/atomic/detail/storage_type.hpp:66:8: note: provided for ‘template<long unsigned int Size> struct boost::atomics::detail::make_storage_type’
 struct make_storage_type
        ^
In file included from ./boost/atomic/detail/operations_lockfree.hpp:21:0,
                 from libs/atomic/src/lockpool.cpp:22:
/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:355:82: error: template argument 1 is invalid
     public gcc_atomic_operations< typename make_storage_type< 1u, Signed >::type >
                                                                                  ^
/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:356:1: error: expected ‘::’ before ‘{’ token
 {
 ^
/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:356:1: error: expected class-name before ‘{’ token
libs/atomic/src/lockpool.cpp:59:26: error: ‘storage_type’ in ‘boost::atomics::detail::{anonymous}::lock_operations {aka struct boost::atomics::detail::operations<1ul, false>}’ does not name a type
 typedef lock_operations::storage_type lock_type;
                          ^
libs/atomic/src/lockpool.cpp:64:28: error: ‘lock_type’ was not declared in this scope
     padding_size = (sizeof(lock_type) <= BOOST_ATOMIC_CACHE_LINE_SIZE ?
                            ^
libs/atomic/src/lockpool.cpp:65:48: error: ‘lock_type’ was not declared in this scope
         (BOOST_ATOMIC_CACHE_LINE_SIZE - sizeof(lock_type)) :
                                                ^
libs/atomic/src/lockpool.cpp:66:48: error: ‘lock_type’ was not declared in this scope
         (BOOST_ATOMIC_CACHE_LINE_SIZE - sizeof(lock_type) % BOOST_ATOMIC_CACHE_LINE_SIZE))
                                                ^
libs/atomic/src/lockpool.cpp:72:5: error: ‘lock_type’ does not name a type
     lock_type lock;
     ^
libs/atomic/src/lockpool.cpp:80:5: error: ‘lock_type’ does not name a type
     lock_type lock;
     ^
libs/atomic/src/lockpool.cpp: In constructor ‘boost::atomics::detail::lockpool::scoped_lock::scoped_lock(const volatile void*)’:
libs/atomic/src/lockpool.cpp:109:111: error: ‘boost::atomics::detail::{anonymous}::padded_lock_t {aka struct boost::atomics::detail::{anonymous}::padded_lock<0u>}’ has no member named ‘lock’
     m_lock(&g_lock_pool[reinterpret_cast< std::size_t >(addr) % (sizeof(g_lock_pool) / sizeof(*g_lock_pool))].lock)
                                                                                                               ^
libs/atomic/src/lockpool.cpp:111:12: error: ‘test_and_set’ is not a member of ‘boost::atomics::detail::{anonymous}::lock_operations {aka boost::atomics::detail::operations<1ul, false>}’
     while (lock_operations::test_and_set(*static_cast< lock_type* >(m_lock), memory_order_acquire))
            ^
libs/atomic/src/lockpool.cpp:111:56: error: ‘lock_type’ does not name a type
     while (lock_operations::test_and_set(*static_cast< lock_type* >(m_lock), memory_order_acquire))
                                                        ^
libs/atomic/src/lockpool.cpp:111:65: error: expected ‘>’ before ‘*’ token
     while (lock_operations::test_and_set(*static_cast< lock_type* >(m_lock), memory_order_acquire))
                                                                 ^
libs/atomic/src/lockpool.cpp:111:65: error: expected ‘(’ before ‘*’ token
libs/atomic/src/lockpool.cpp:111:67: error: expected primary-expression before ‘>’ token
     while (lock_operations::test_and_set(*static_cast< lock_type* >(m_lock), memory_order_acquire))
                                                                   ^
libs/atomic/src/lockpool.cpp:112:5: error: expected ‘)’ before ‘{’ token
     {
     ^
libs/atomic/src/lockpool.cpp:117:18: error: ‘load’ is not a member of ‘boost::atomics::detail::{anonymous}::lock_operations {aka boost::atomics::detail::operations<1ul, false>}’
         while (!!lock_operations::load(*static_cast< lock_type* >(m_lock), memory_order_relaxed));
                  ^
libs/atomic/src/lockpool.cpp:117:54: error: ‘lock_type’ does not name a type
         while (!!lock_operations::load(*static_cast< lock_type* >(m_lock), memory_order_relaxed));
                                                      ^
libs/atomic/src/lockpool.cpp:117:63: error: expected ‘>’ before ‘*’ token
         while (!!lock_operations::load(*static_cast< lock_type* >(m_lock), memory_order_relaxed));
                                                               ^
libs/atomic/src/lockpool.cpp:117:63: error: expected ‘(’ before ‘*’ token
libs/atomic/src/lockpool.cpp:117:65: error: expected primary-expression before ‘>’ token
         while (!!lock_operations::load(*static_cast< lock_type* >(m_lock), memory_order_relaxed));
                                                                 ^
libs/atomic/src/lockpool.cpp:117:98: error: expected ‘)’ before ‘;’ token
         while (!!lock_operations::load(*static_cast< lock_type* >(m_lock), memory_order_relaxed));
                                                                                                  ^
libs/atomic/src/lockpool.cpp: In destructor ‘boost::atomics::detail::lockpool::scoped_lock::~scoped_lock()’:
libs/atomic/src/lockpool.cpp:123:5: error: ‘clear’ is not a member of ‘boost::atomics::detail::{anonymous}::lock_operations {aka boost::atomics::detail::operations<1ul, false>}’
     lock_operations::clear(*static_cast< lock_type* >(m_lock), memory_order_release);
     ^
libs/atomic/src/lockpool.cpp:123:42: error: ‘lock_type’ does not name a type
     lock_operations::clear(*static_cast< lock_type* >(m_lock), memory_order_release);
                                          ^
libs/atomic/src/lockpool.cpp:123:51: error: expected ‘>’ before ‘*’ token
     lock_operations::clear(*static_cast< lock_type* >(m_lock), memory_order_release);
                                                   ^
libs/atomic/src/lockpool.cpp:123:51: error: expected ‘(’ before ‘*’ token
libs/atomic/src/lockpool.cpp:123:53: error: expected primary-expression before ‘>’ token
     lock_operations::clear(*static_cast< lock_type* >(m_lock), memory_order_release);
                                                     ^

    "/usr/bin/aarch64-linux-gnu-g++"   -fPIC -pthread -O3 -finline-functions -Wno-inline -Wall  -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_ATOMIC_SOURCE -DNDEBUG  -I"." -c -o "bin.v2/libs/atomic/build/gcc-arm/release/threading-multi/lockpool.o" "libs/atomic/src/lockpool.cpp"

...failed gcc.compile.c++ bin.v2/libs/atomic/build/gcc-arm/release/threading-multi/lockpool.o...
...skipped <pbin.v2/libs/atomic/build/gcc-arm/release/threading-multi>libboost_atomic.so.1.68.0 for lack of <pbin.v2/libs/atomic/build/gcc-arm/release/threading-multi>lockpool.o...
...skipped <p/opt/cross/boost/lib>libboost_atomic.so.1.68.0 for lack of <pbin.v2/libs/atomic/build/gcc-arm/release/threading-multi>libboost_atomic.so.1.68.0...
...skipped <p/opt/cross/boost/lib>libboost_atomic.so for lack of <p/opt/cross/boost/lib>libboost_atomic.so.1.68.0...

...

Any thoughts on how to get round this?

Incorrect const qualifier?

Using a near-trunk build of clang which as a new semantic check, I get this error:

include/boost/atomic/detail/ops_gcc_x86_dcas.hpp:408:16: error: address argume\nt to atomic builtin cannot be const-qualified ('const volatile boost::atomics::detail::gcc_dcas_x86_64::storage_type *' (aka 'constvolatile unsigned __int128 *') invalid)
        return __sync_val_compare_and_swap(&storage, value, value);
               ^                           ~~~~~~~~
1 error generated.

which is generated due to the "const" declaration in this static function:
https://github.com/boostorg/atomic/blob/develop/include/boost/atomic/detail/ops_gcc_x86_dcas.hpp#L402

The error seems correct but so does the code. I worked around this by casting away the const operand to the intrinsic.

        return __sync_val_compare_and_swap(
            const_cast<storage_type volatile*>(&storage), value, value);

(op)_and_test

It seems like an unfortunate choice that these return true when the result is zero, rather than when it is non-zero. It's the opposite of both the standard if-operator-bool logic and the bitwise test operations.

Any chance this can be "fixed" for the next version, breaking change though that would be?

atomic_ref caveats section regarding padding bits should be expanded

Consider the following examples:

#include <boost/atomic/atomic_ref.hpp>

int main()
{
    struct FourBits
    {
        char b : 4;
    };

    alignas(boost::atomic_ref<FourBits>::required_alignment) FourBits b1;
    FourBits b2, b3;

    memcpy(&b1, "\xF1", 1);
    memcpy(&b2, "\xA1", 1);
    memcpy(&b3, "\x52", 1);

    assert(b1.b == 1);
    assert(b2.b == 1);
    assert(b3.b == 2);

    boost::atomic_ref<FourBits>(b1).compare_exchange_strong(b2, b3);

    assert(b1.b == 2); // this fails
}

and:

int main()
{
    struct FourBytes
    {
        short a;
        char  b;
    };

    alignas(boost::atomic_ref<FourBytes>::required_alignment) FourBytes b1;
    FourBytes b2, b3;

    memcpy(&b1, "\x00\x00\x01\xF0", sizeof(FourBytes));
    memcpy(&b2, "\x00\x00\x01\xA0", sizeof(FourBytes));
    memcpy(&b3, "\x00\x00\x02\x50", sizeof(FourBytes));

    assert(b1.b == 1);
    assert(b2.b == 1);
    assert(b3.b == 2);

    boost::atomic_ref<FourBytes>(b1).compare_exchange_strong(b2, b3);

    assert(b1.b == 2); // this fails
}

Both fail, but I believe according to http://wg21.link/p1123r0 should succeed.

I don't think it can be done without compiler support, or too much overhead, so probably caveats documentation should be expanded.

UWP support

The library cannot be built for UWP because there is no boost::winapi::get_module_handle (::GetModuleHandle)

compile-c-c++ D:\buildtrees\boost-atomic\x64-uwp-dbg\boost\build\9357143429b3339f991610d5cdc76bfc\wait_on_address.obj

    call "D:\buildtrees\boost-atomic\x64-uwp-dbg\boost\standalone\msvc\6b07b0b0f8e08318738a96bc606093b3\msvc-setup.bat" amd64 >nul
 cl "..\src\wait_on_address.cpp" -c -Fo"D:\buildtrees\boost-atomic\x64-uwp-dbg\boost\build\9357143429b3339f991610d5cdc76bfc\wait_on_address.obj"     -TP /wd4675 /EHs /GR /Zc:throwingNew /nologo /DWIN32 /D_WINDOWS /W3 /utf-8 /GR /EHsc /MP /D_DEBUG /MDd /Z7 /Ob0 /Od /RTC1 /ZW /Z7 /Od /Ob0 /W3 /MDd /AI"C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs\14.0\References\CommonConfiguration\neutral" /AI"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\lib\x86\store\references" /AI"C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.19041.0" /AI"C:\Program Files (x86)\Windows Kits\10\References\10.0.19041.0" /AI"C:\Windows\Microsoft.NET\Framework64\v4.0.30319" /D_WIN32_WINNT=0x0A00 /Zc:forScope /Zc:wchar_t /Zc:inline /favor:blend -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_ATOMIC_SOURCE -DBOOST_ATOMIC_USE_SSE2 -DBOOST_ATOMIC_USE_SSE41 -DBOOST_USE_WINDOWS_H -DWINAPI_FAMILY=WINAPI_FAMILY_APP "-I..\include" "-ID:\installed\x64-uwp\include" "-I..\src" 

wait_on_address.cpp
..\src\wait_on_address.cpp(60): error C2039: 'get_module_handle': is not a member of 'boost::winapi'
D:\installed\x64-uwp\include\boost/winapi/dll.hpp(190): note: see declaration of 'boost::winapi'
..\src\wait_on_address.cpp(60): error C3861: 'get_module_handle': identifier not found
..\src\wait_on_address.cpp(63): error C2039: 'get_proc_address': is not a member of 'boost::winapi'
D:\installed\x64-uwp\include\boost/winapi/dll.hpp(190): note: see declaration of 'boost::winapi'
..\src\wait_on_address.cpp(63): error C3861: 'get_proc_address': identifier not found
..\src\wait_on_address.cpp(66): error C2039: 'get_proc_address': is not a member of 'boost::winapi'
D:\installed\x64-uwp\include\boost/winapi/dll.hpp(190): note: see declaration of 'boost::winapi'
..\src\wait_on_address.cpp(66): error C3861: 'get_proc_address': identifier not found
..\src\wait_on_address.cpp(67): error C2039: 'get_proc_address': is not a member of 'boost::winapi'
D:\installed\x64-uwp\include\boost/winapi/dll.hpp(190): note: see declaration of 'boost::winapi'
..\src\wait_on_address.cpp(67): error C3861: 'get_proc_address': identifier not found
compile-c-c++ D:\buildtrees\boost-atomic\x64-uwp-dbg\boost\build\9357143429b3339f991610d5cdc76bfc\lock_pool.obj

boost::atomic<T>::wait (P1135R5, C++20)

I want to have wait, notify_one and notify_all added to boost::atomic, as defined in P1135R5 proposal.

Also would be nice to have an extension:
instead of returning void, wait could return observed new value.

gcc x86 dcas assembly issue

We ran into this crash issue when using x86 32bit boost + gcc 4.6 (-O2 or higher).

I think the part is buggy, in atomic/include/boost/atomic/detail/ops_gcc_x86_dcas.hpp:

        uint32_t scratch;
        __asm__ __volatile__
        (
            "movl %%ebx, %[scratch]\n\t"
            "movl %[value_lo], %%ebx\n\t"
            "movl %[dest], %%eax\n\t"
            "movl 4+%[dest], %%edx\n\t"
            ".align 16\n\t"
            "1: lock; cmpxchg8b %[dest]\n\t"
            "jne 1b\n\t"
            "movl %[scratch], %%ebx\n\t"
            : [scratch] "=m" (scratch), [dest] "=o" (storage)
            : [value_lo] "a" ((uint32_t)v), "c" ((uint32_t)(v >> 32))
            : BOOST_ATOMIC_DETAIL_ASM_CLOBBER_CC_COMMA "edx", "memory"
        );

Problem is that eax is touched, but not clobbered: We need to put it as a dummy output to tell the compiler that, otherwise the compiler may reuse eax and taking it as not changed.

Actually the case in you lockfree::queue::initialization function will trigger this bug in some situations.

Pragma push reported missing

.....\boost/atomic/detail/memory_order_utils.hpp(45) : warning C4193: #pragma warning(pop) : no matching '#pragma warning(push)'

and I suspect this may be causing trouble by wrongly popping elsewhere?

warning: unused parameter 'order'

This program:

#include <boost/atomic.hpp>
int main() {
  return 0;
}

cross-compiled from linux x86_64 to OSX 10.9 with clang++ 5.0.2 with the following command:
i386-apple-darwin13-clang++-libc++ -o atomic.o -c -Wall -Wextra -std=c++14 -m32 -mmacosx-version-min=10.9 -I/softs/osx32-clang-5.0.2/release/boost/include atomic.cpp
gives the following warning:

In file included from atomic.cpp:1:
In file included from /softs/osx32-clang-5.0.2/release/boost/include/boost/atomic.hpp:12:
In file included from /softs/osx32-clang-5.0.2/release/boost/include/boost/atomic/atomic.hpp:20:
In file included from /softs/osx32-clang-5.0.2/release/boost/include/boost/atomic/fences.hpp:21:
In file included from /softs/osx32-clang-5.0.2/release/boost/include/boost/atomic/detail/operations.hpp:17:
In file included from /softs/osx32-clang-5.0.2/release/boost/include/boost/atomic/detail/operations_lockfree.hpp:21:
In file included from /softs/osx32-clang-5.0.2/release/boost/include/boost/atomic/detail/ops_gcc_atomic.hpp:24:
/softs/osx32-clang-5.0.2/release/boost/include/boost/atomic/detail/ops_gcc_x86_dcas.hpp:269:113: warning: unused parameter 'order' [-Wunused-parameter]
    static BOOST_FORCEINLINE storage_type exchange(storage_type volatile& storage, storage_type v, memory_order order) BOOST_NOEXCEPT
                                                                                                                ^
1 warning generated.

Possible build configuration error?

Steps to reproduce:

  1. Check out current develop of boost and update all submodules.
  2. Ensure clang is installed (I am using clang-10, but it's probably not important)
  3. Execute the following statements in a bash shell:
$ ./bootstrap.sh
$ ./b2 toolset=clang variant=release,debug cxxstd=2a,17,14,11 -j`grep processor /proc/cpuinfo | wc -l` test

Observed Results:

... time passes...

error: Name clash for '<p/devel/boost/stage/lib>libboost_atomic.so.1.74.0'
error: 
error: Tried to build the target twice, with property sets having 
error: these incompatible properties:
error: 
error:     -  <cxxstd>2a
error:     -  <cxxstd>17
error: 
error: Please make sure to have consistent requirements for these 
error: properties everywhere in your project, especially for install
error: targets.

Expected Results:

Completion of configuration, compilation and tests passing.

Consider not using _mm_mfence even when it is available

Consider either making BOOST_ATOMIC_NO_MFENCE overriding detection of SSE2 or x64, or even always defaulting to not using mfence.

The reason is that mfence is slower than a dummy interlocked operation.

On x64 there's even an intrinsic for that - see __faststorefence

There might be a reason to use precisely mfence. An interlocked operation does not provide fences to non-temporal stores. But this is out of scope for implementing C++ memory model on x86 in the usual way.

Cannot get boost::atomic_ref to compile using a const integer

Hi,

I'm trying to build the following code on Xcode 14.2 and boost 1.82.0 but I get a strange compilation error. Here's the code that's not compiling:

#include "boost/atomic.hpp"

int main(int argc, const char * argv[]) {
	const unsigned long		i=4;
	unsigned long			j=6;

	boost::atomic_ref<unsigned long>	ar0{j};
	auto	val0{ar0.load(boost::memory_order::acquire)};
	(void) val0;

	boost::atomic_ref<const unsigned long>	ar1{i};
	auto	val1{ar1.load(boost::memory_order::acquire)};
	(void) val1;
}

And here's the error that clang generates:

In file included from ../boost_1_82_0/boost/atomic.hpp:16:
In file included from ../boost_1_82_0/boost/atomic/atomic_ref.hpp:24:
../boost_1_82_0/boost/atomic/detail/atomic_ref_impl.hpp:99:17: error: reinterpret_cast from 'boost::atomics::detail::base_atomic_ref_common<const unsigned long, false, false>::value_type *' (aka 'const unsigned long *') to 'boost::atomics::detail::base_atomic_ref_common<const unsigned long, false, false>::storage_type *' (aka 'unsigned long long *') casts away qualifiers
        return *reinterpret_cast< storage_type* >(m_value);
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../boost_1_82_0/boost/atomic/detail/atomic_ref_impl.hpp:425:88: note: in instantiation of member function 'boost::atomics::detail::base_atomic_ref_common<const unsigned long, false, false>::storage' requested here
        return atomics::detail::bitwise_cast< value_type >(core_operations::load(this->storage(), order));
                                                                                       ^
/Users/---/test_boost_atomic_ref/test_boost_atomic_ref/main.cpp:34:16: note: in instantiation of member function 'boost::atomics::detail::base_atomic_ref<const unsigned long, int, false>::load' requested here
        auto    val1{ar1.load(boost::memory_order::acquire)};
                         ^
1 error generated.

In case it will help, here's the clang version:

% clang -v

Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin21.6.0

Thanks for any help you can provide. Is this a bug in the boost/atomic library?

Cross compilation issues on x86 to A64FX

Hi,

I am working to compile Boost on Fugaku using the Fujitsu compiler. I could compile boost 1.78 on A64fx successfully, however, with cross compilation, the following error occurs

"./boost/atomic/detail/caps_arch_gcc_aarch64.hpp", line 34: catastrophic error: #error directive: "Boost.Atomic: Failed to determine AArch64 endianness, the target platform is not supported. Please, report to the developers (patches are welcome)."
  #error "Boost.Atomic: Failed to determine AArch64 endianness, the target platform is not supported. Please, report to the developers (patches are welcome)."

Any ideas why I can compile directly, but not cross compile?

Error: "Failed to determine builtin floating point type sizes"

Hi,

I received an error telling me to make a bug report here ;)
I am using GCC 8.1.1 on OpenSUSE Tumbleweed. The project itself is a huge chunk of cmake spaghetti code so I used a quick @echo to print out the exact command:

/usr/bin/g++ -frounding-math -std=c++11 -Wuninitialized -Wno-error=unused-variable -DBOOST_NO_AUTO_PTR -DBOOST_SYSTEM_NO_DEPRECATED=1 -fopenmp -Wall -ftemplate-depth-100 -frounding-math -Wno-misleading-indentation -Wno-placement-new -Wno-expansion-to-defined -Wno-long-long -Wno-unknown-pragmas -Wno-comment -Wno-address -Wno-error=address -Wno-expansion-to-defined -g

The error I was talking of:

/.../boost_gcc_debug/include/boost/atomic/detail/float_sizes.hpp:139:2: error: #error Boost.Atomic: Failed to determine builtin floating point type sizes, the target platform is not supported. Please, report to the developers (patches are welcome).

 #error Boost.Atomic: Failed to determine builtin floating point type sizes, the target platform is not supported. Please, report to the developers (patches are welcome).

Simon

Remove or fix relative includes

On some systems relative includes are not automatically possible, i.e. the path to the current source file may not automatically added to the include-path.

Currently Boost.Atomic fails on Cygwin 3.1.7 with:

libs\atomic\src\find_address_sse2.cpp:25:10: fatal error: find_address.hpp: No such file or directory
   25 | #include "find_address.hpp"
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.
libs\atomic\src\find_address_sse41.cpp:25:10: fatal error: find_address.hpp: No such file or directory
   25 | #include "find_address.hpp"
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.

According to https://www.appveyor.com/docs/windows-images-software/#mingw-msys-cygwin the Appveyor images 2015&2017 use Cygwin 3.0.7 while the newer 2019&2022 use 3.1.7 where those failures appear. Hence I'd suggest to add CI for both.

Fails to build with `toolset=msvc-14.0 cxxstd=latest`

With the following error:

compile-c-c++ ..\..\bin.v2\libs\atomic\build\msvc-14.0\debug\cxxstd-latest-iso\threading-multi\lock_pool.obj
lock_pool.cpp
C:\boost-git\develop\boost/atomic/detail/type_traits/has_unique_object_representations.hpp(33): error C2039: 'has_unique_object_representations': is not a member of 'std'
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\limits(18): note: see declaration of 'std'
C:\boost-git\develop\boost/atomic/detail/type_traits/has_unique_object_representations.hpp(33): error C2873: 'has_unique_object_representations': symbol cannot be used in a using-declaration

and

compile-c-c++ ..\..\bin.v2\libs\filesystem\build\msvc-14.0\debug\cxxstd-latest-iso\threading-multi\path.obj
path.cpp
C:\boost-git\develop\boost/atomic/detail/type_traits/has_unique_object_representations.hpp(33): error C2039: 'has_unique_object_representations': is not a member of 'std'
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\algorithm(14): note: see declaration of 'std'
C:\boost-git\develop\boost/atomic/detail/type_traits/has_unique_object_representations.hpp(33): error C2873: 'has_unique_object_representations': symbol cannot be used in a using-declaration

and so on.

I was surprised that this trait went into C++17, I don't remember as part of what changes. But in any case, VS 2015 doesn't seem to have it.

Document that BOOST_ATOMIC_NO_CMPXCHG8B may be not useful for MSVC

Windows requires:

  • cmpxchg8b starting Windows XP
  • cmpxchg16b starting Windows 8

Visual Studio 2012 thru 2019 support Windows XP as the minimum version, and it even takes special toolset to be used. (Actually even 2019 supports XP by using the toolset from VS 20117).

It means that it is not useful to use BOOST_ATOMIC_NO_CMPXCHG8B starting VS 2012.
Consider documenting it.

Architecture Info

at last found this after search in many library's:
1: after download
2: placed it at "3rdParty/boost/*"
3: and then included the header "atomic.hpp"

all fine until now but:
I needed to edit the headers since I did not wanted to over-fill my include path since I do just use the "atomic" from the entire "boost" library and for other things I use "Qt".
and also I did not wanted to confuse anyone with access to my source code.

any-way I think the mentioned three steps should be enough to get started could you please do this.

File is missing: lock_pool_init1.ipp

The file lock_pool_init1.ipp is not found when compiling Boost.Atomic.

The file exists, but can't be found. So the error can be mitigated by using:

cp boost_1_75_0/libs/atomic/src/lock_pool_init1.ipp boost_1_75_0/include/boost/preprocessor/iteration/detail/iter/limits/lock_pool_init1.ipp

But that is obviously a workaround. What is the structural solution? Or is it an issue within the library? We had the same with 1.74.0 but in 1.75.0 we still have it.

This is my minimal reproduction scenario:

clang -I boost_1_75_0/include -std=c++14 -MD -MT /tmp/lock_pool.cpp.o -MF /tmp/lock_pool.cpp.o.d -o /tmp/lock_pool.cpp.o -c boost_1_75_0/libs/atomic/src/lock_pool.cpp

The complete error message:

In file included from boost_1_75_0/libs/atomic/src/lock_pool.cpp:1120:
In file included from boost_1_75_0/include/boost/preprocessor/iteration/detail/iter/forward1.hpp:1343:
boost_1_75_0/include/boost/preprocessor/iteration/detail/iter/limits/forward1_256.hpp:19:18: fatal error: 'lock_pool_init1.ipp' file not found
#        include BOOST_PP_FILENAME_1
                 ^
boost_1_75_0/include/boost/preprocessor/iteration/detail/iter/forward1.hpp:29:56: note: expanded from macro 'BOOST_PP_FILENAME_1'
#    define BOOST_PP_FILENAME_1 BOOST_PP_ARRAY_ELEM(2, BOOST_PP_ITERATION_PARAMS_1)
                                                       ^
boost_1_75_0/libs/atomic/src/lock_pool.cpp:1118:81: note: expanded from macro 'BOOST_PP_ITERATION_PARAMS_1'
#define BOOST_PP_ITERATION_PARAMS_1 (3, (1, BOOST_ATOMIC_DETAIL_LOCK_POOL_SIZE, "lock_pool_init1.ipp"))
                                                                                ^~~~~~~~~~~~~~~~~~~~~
boost_1_75_0/include/boost/preprocessor/array/elem.hpp:23:114: note: expanded from macro 'BOOST_PP_ARRAY_ELEM'
#    define BOOST_PP_ARRAY_ELEM(i, array) BOOST_PP_TUPLE_ELEM(BOOST_PP_ARRAY_SIZE(array), i, BOOST_PP_ARRAY_DATA(array))
                                                                                                                 ^
note: (skipping 10 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
boost_1_75_0/include/boost/preprocessor/tuple/rem.hpp:30:28: note: expanded from macro 'BOOST_PP_REM'
# define BOOST_PP_REM(...) __VA_ARGS__
                           ^
boost_1_75_0/include/boost/preprocessor/variadic/elem.hpp:27:86: note: expanded from macro 'BOOST_PP_VARIADIC_ELEM'
#     define BOOST_PP_VARIADIC_ELEM(n, ...) BOOST_PP_CAT(BOOST_PP_VARIADIC_ELEM_, n)(__VA_ARGS__,)
                                                                                     ^
boost_1_75_0/include/boost/preprocessor/variadic/limits/elem_64.hpp:18:55: note: expanded from macro 'BOOST_PP_VARIADIC_ELEM_2'
#    define BOOST_PP_VARIADIC_ELEM_2(e0, e1, e2, ...) e2
                                                      ^
1 error generated.

And this is the message in gcc:

boost_1_75_0/libs/atomic/src/lock_pool.cpp:1118:81: fatal error: lock_pool_init1.ipp: No such file or directory
 #define BOOST_PP_ITERATION_PARAMS_1 (3, (1, BOOST_ATOMIC_DETAIL_LOCK_POOL_SIZE, "lock_pool_init1.ipp"))
                                                                                 ^~~~~~~~~~~~~~~~~~~~~
compilation terminated.

crashes on android

we are experiencing issues that seem to be traceable to boost atomic on android (specifically Nexus 7 2013). see libtorrent issue
could you please advise us on the correct compile options for this platform?

we are trying the default settings (no special flags), and also -DBOOST_ASIO_DISABLE_STD_ATOMIC=1 -DBOOST_SP_NO_ATOMIC_ACCESS=1, but still see the issue.

we are not trying to build boost.thread; libtorrent just uses it as a header library. is that correct? when would you need to build boost.thread?

Boost atomics on aarch64 produce invalid instructions

Certain atomic operations result in invalid inline assembly (to large immediate values) to be generated.

Reproducer:

#include <boost/atomic.hpp>

boost::atomic<int> data;

// test atomics for aarch64 with boost 1.74.0
void test() {
    // produces a "and w1,w1,64" instruction (valid)
    data.bitwise_and(64, boost::memory_order_relaxed); 
    // produces a "orr w2,w2,32" instruction (valid)
    data.bitwise_or(32, boost::memory_order_relaxed);
    // produces a "eor w2,w2,32" instruction (valid)
    data.bitwise_xor(32, boost::memory_order_relaxed);

    // produces a "and w1,w1,76" instruction (invalid, valid up to 64)
    data.bitwise_and(76, boost::memory_order_relaxed);
    // produces a "orr w2,w2,59" instruction (invalid, valid up to 32)
    data.bitwise_or(59, boost::memory_order_relaxed);
    // produces a "eor w2,w2,42" instruction (invalid, valid up to 32)
    data.bitwise_xor(42, boost::memory_order_relaxed);
}

Output:

/tmp/cc5EHm5U.s: Assembler messages:
/tmp/cc5EHm5U.s:104: Error: immediate out of range at operand 3 -- `and w2,w2,76'
/tmp/cc5EHm5U.s:128: Error: immediate out of range at operand 3 -- `orr w2,w2,59'
/tmp/cc5EHm5U.s:152: Error: immediate out of range at operand 3 -- `eor w2,w2,42'
Compiler returned: 1

Example at: https://godbolt.org/z/9cYnq3

atomic/detail/fence_arch_ops_gcc_arm.hpp:70:13: error: expected string literal in 'asm'

https://www.boost.org/development/tests/develop/developer/output/teeks99-05-dg8-2a-64onarmv7l-boost-bin-v2-libs-atomic-test-atomic_api-test-gcc-8~c++2a-debug-address-model-64-threadapi-pthread-threading-multi-visibility-hidden.html

    "g++-8"   -fvisibility-inlines-hidden -std=c++2a -fPIC -pthread -O0 -fno-inline -Wall -g -fvisibility=hidden  -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_BEAST_ALLOW_DEPRECATED -DBOOST_BEAST_SEPARATE_COMPILATION -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1  -I".."  -c -o "/mnt/fs1/teeks99-05/run/results/boost/bin.v2/libs/atomic/test/atomic_api.test/gcc-8~c++2a/debug/address-model-64/threadapi-pthread/threading-multi/visibility-hidden/atomic_api.o" "../libs/atomic/test/atomic_api.cpp"

In file included from ../boost/atomic/detail/fence_arch_operations.hpp:21,
                 from ../boost/atomic/detail/ops_gcc_arm_common.hpp:22,
                 from ../boost/atomic/detail/core_arch_ops_gcc_arm.hpp:26,
                 from ../boost/atomic/detail/core_arch_operations.hpp:24,
                 from ../boost/atomic/detail/core_operations.hpp:19,
                 from ../boost/atomic/detail/atomic_impl.hpp:27,
                 from ../boost/atomic/atomic.hpp:26,
                 from ../boost/atomic.hpp:15,
                 from ../libs/atomic/test/atomic_api.cpp:8:
../boost/atomic/detail/fence_arch_ops_gcc_arm.hpp: In static member function ???static void boost::atomics::detail::fence_arch_operations_gcc_arm::hardware_full_fence()???:
../boost/atomic/detail/fence_arch_ops_gcc_arm.hpp:70:13: error: expected string-literal before ???BOOST_ATOMIC_DETAIL_ARM_ASM_START???
             BOOST_ATOMIC_DETAIL_ARM_ASM_START(%0)
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.