[lockfree] arm / iOS builds against Boost.Atomic
Hello, I noticed today when moving my work from OS X / clang / libc++ to iOS / clang / libc++ that Boost.Lockfree must link against libboost_atomic.a to compile. This shouldn't be necessary, since there is std::atomic on iOS as well. If this is correct I can file a bug report, provide a test application, or both if requested. cheers, Rich
I noticed today when moving my work from OS X / clang / libc++ to iOS / clang / libc++ that Boost.Lockfree must link against libboost_atomic.a to compile. This shouldn't be necessary, since there is std::atomic on iOS as well.
i don't have access to this specific toolchain, so it is probably using boost::atomic instead of std::atomic ... however please note that linking with boost.atomic means that the data structure that you want to use is not going to be lock-free, but atomics are emulated via spin locks.
If this is correct I can file a bug report, provide a test application, or both if requested.
On 5/14/2013 11:35 PM, Tim Blechmann wrote:
I noticed today when moving my work from OS X / clang / libc++ to iOS / clang / libc++ that Boost.Lockfree must link against libboost_atomic.a to compile. This shouldn't be necessary, since there is std::atomic on iOS as well.
This is true if you're compiling with -std=gnu++11. It's possible to compile for iOS without std::atomic being available with gcc and clang. The point still stands though, it'd be good to use std::atomic if it's available.
i don't have access to this specific toolchain, so it is probably using boost::atomic instead of std::atomic ... however please note that linking with boost.atomic means that the data structure that you want to use is not going to be lock-free, but atomics are emulated via spin locks.
Why's that?
I noticed today when moving my work from OS X / clang / libc++ to iOS / clang / libc++ that Boost.Lockfree must link against libboost_atomic.a to compile. This shouldn't be necessary, since there is std::atomic on iOS as well.
This is true if you're compiling with -std=gnu++11. It's possible to compile for iOS without std::atomic being available with gcc and clang.
The point still stands though, it'd be good to use std::atomic if it's available.
would be great if someone who has access to the toolchain could send a patch. the file in question is: boost/lockfree/detail/atomic.hpp
i don't have access to this specific toolchain, so it is probably using boost::atomic instead of std::atomic ... however please note that linking with boost.atomic means that the data structure that you want to use is not going to be lock-free, but atomics are emulated via spin locks.
Why's that?
not sure if arm supports a double-width compare-and-swap or ll/sc tim
Ah, just dug a little further and realized boost::atomic is always used
with clang be it the OS X or iOS / arm toolchain. But for whatever reason
only arm required me to link against libboost_atomic.a. Nonetheless, there
should be a test machine at least running libc++ / C++11 already.
On Wed, May 15, 2013 at 1:48 AM, Tim Blechmann
would be great if someone who has access to the toolchain could send a patch. the file in question is: boost/lockfree/detail/atomic.hpp
I would be happy to help if I can. We at least need libc++ (_LIBCPP_VERSION should be defined if so), atomics have been around there since 3.1, although I'm not sure the best way to ensure they are available on the given system. One way to go is: #if defined( BOOST_CLANG ) #if __has_include( <atomic> ) // we're good #endif #enfif although in my own code I just rely on if _LIBCPP_VERSION is there since I am using apple's toolchains. not sure if arm supports a double-width compare-and-swap or ll/sc
AFAIK <atomic> is complete in libc++. Is there any way to (stress) test this?
I would be happy to help if I can. We at least need libc++ (_LIBCPP_VERSION should be defined if so), atomics have been around there since 3.1, although I'm not sure the best way to ensure they are available on the given system. One way to go is:
#if defined( BOOST_CLANG ) #if __has_include( <atomic> ) // we're good #endif #enfif
although in my own code I just rely on if _LIBCPP_VERSION is there since I am using apple's toolchains.
hmm, maybe checks for both would be needed. e.g. some compilers have <atomic>, but don't implement it completely ... quite a mess ... so i'm rather conservative about using std::atomic (clang/libstdc++ might cause some problems) ... but enabling std::atomic via _LIBCPP_VERSION is probably safe ... cheers, tim
On 17 May 2013 02:46, Tim Blechmann wrote:
hmm, maybe checks for both would be needed. e.g. some compilers have <atomic>, but don't implement it completely ... quite a mess ... so i'm rather conservative about using std::atomic (clang/libstdc++ might cause some problems) ... but enabling std::atomic via _LIBCPP_VERSION is probably safe ...
What's missing from libstdc++'s <atomic> on arm?
On Fri, May 17, 2013 at 5:54 AM, Jonathan Wakely
On 17 May 2013 02:46, Tim Blechmann wrote:
hmm, maybe checks for both would be needed. e.g. some compilers have <atomic>, but don't implement it completely ... quite a mess ... so i'm rather conservative about using std::atomic (clang/libstdc++ might cause some problems) ... but enabling std::atomic via _LIBCPP_VERSION is probably safe ...
What's missing from libstdc++'s <atomic> on arm?
I believe nothing with gcc 4.8, but no arm device toolchain uses that version yet (android is on 4.6 as of March 2013). Apple's version of gcc is something horrible like 4.2.
On Wed, May 15, 2013 at 1:34 AM, Michael Marcin
This is true if you're compiling with -std=gnu++11. It's possible to compile for iOS without std::atomic being available with gcc and clang.
It's actually only true of you are both compiling for C++11 and with libc++, but this is now standard on Mac OS X and iOS.
Hi Rich, Rich E wrote:
I noticed today when moving my work from OS X / clang / libc++ to iOS / clang / libc++ that Boost.Lockfree must link against libboost_atomic.a to compile. This shouldn't be necessary, since there is std::atomic on iOS as well.
I wrote the Boost.Atomic support for ARM. As you may have noticed, Boost.Atomic was a long time in gestation and has been somewhat overtaken by events, i.e. there is vendor-supplied <atomic> support on many systems, making Boost.Atomic useful primarily for people who cannot use latest versions of compilers. Although I'm still using this code myself on iOS and ARM Linux, I probably won't be for much longer. Having said that, I suggest always checking to see what code is actually being generated i.e. is it inline atomic instructions (ldrex & strex on ARM) or some kind of library call, even with vendor-supplied <atomic> implementations. Just look at the generated assembler for a trivial program. The fact that you're seeing a requirement to link with Boost.Atomic suggests that it is not using my inline-assembler version... explained by this post from Tim:
not sure if arm supports a double-width compare-and-swap or ll/sc
IIRC, ARMv7and later does - but my code doesn't support it. It could probably be added quite easily. I didn't have a platform to test that on when I wrote it. Regards, Phil.
hi phil,
not sure if arm supports a double-width compare-and-swap or ll/sc IIRC, ARMv7and later does - but my code doesn't support it. It could probably be added quite easily. I didn't have a platform to test that on when I wrote it.
hmmm ... interesting ... would you be able to provide a patch for this? then boost.lockfree would actually be lock-free on many arm devices! thnx, tim
Patch is attached to the ticket here: https://svn.boost.org/trac/boost/ticket/8593 On Thu, May 16, 2013 at 11:29 AM, Phil Endecott < spam_from_boost_dev@chezphil.org> wrote:
Having said that, I suggest always checking to see what code is actually being generated i.e. is it inline atomic instructions (ldrex & strex on ARM) or some kind of library call, even with vendor-supplied <atomic> implementations. Just look at the generated assembler for a trivial program. The fact that you're seeing a requirement to link with Boost.Atomic suggests that it is not using my inline-assembler version... explained by this post from Tim:
Below is a portion of what I get from the following simple function, I believe it indicates proper atomic support since the instructions you mention are in there. Compiling with clang / libc++ with the tools apple is shipping today (Xcode 4.6, clang 3.2), arch armv7 / armv7s: #include <atomic> void foo() { std::atomic<int> bar( 2 ); bar += 3; } /* Assembly: ... LJTI0_0_0: .data_region jt8 .byte (LBB0_5-LJTI0_0_0)/2 .byte (LBB0_5-LJTI0_0_0)/2 .byte (LBB0_8-LJTI0_0_0)/2 .byte (LBB0_11-LJTI0_0_0)/2 .byte (LBB0_14-LJTI0_0_0)/2 .end_data_region .align 1 LBB0_2: ldr r0, [sp, #96] str r0, [sp, #36] @ 4-byte Spill LBB0_3: @ =>This Inner Loop Header: Depth=1 ldr r0, [sp, #44] @ 4-byte Reload ldrex r1, [r0] ldr r2, [sp, #36] @ 4-byte Reload adds r3, r1, r2 strex r9, r3, [r0] cmp.w r9, #0 str r1, [sp, #32] @ 4-byte Spill bne LBB0_3 @ BB#4: ldr r0, [sp, #32] @ 4-byte Reload str r0, [sp, #92] b LBB0_17 LBB0_5: ldr r0, [sp, #96] str r0, [sp, #28] @ 4-byte Spill LBB0_6: @ =>This Inner Loop Header: Depth=1 ldr r0, [sp, #44] @ 4-byte Reload ldrex r1, [r0] ldr r2, [sp, #28] @ 4-byte Reload adds r3, r1, r2 strex r9, r3, [r0] cmp.w r9, #0 str r1, [sp, #24] @ 4-byte Spill bne LBB0_6 ... */
participants (5)
-
Jonathan Wakely -
Michael Marcin -
Phil Endecott -
Rich E -
Tim Blechmann