[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 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:
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.
Why's that?
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 <tim@klingt.org> wrote:
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?
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
Hi Rich, Rich E wrote:
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.
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:
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