[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)



On Wed, Dec 07, 2016 at 03:53:31PM +0000, Steve McIntyre wrote:
> AFAIK there are potentially still similar problems with ARMv5 - lack
> of architcture-defined barrier primitives for C++11 atomics to
> work. (I'd love to be corrected on this if people know better!) This
> is one of the key points here. More and more software is expecting to
> use these primitives, and a lack of them is a major problem. To
> demonstrate using gcc, you can see that lock-free atomics only started
> appearing in ARMv6 and were improved in ARMv7:
> 
> $ for arch in 4 5 6 7-a; do echo ARMv${arch}; echo | g++ -march=armv${arch} -dM -E - | grep -i lock_free; done
> ARMv4
> #define __GCC_ATOMIC_CHAR_LOCK_FREE 1
> #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
> #define __GCC_ATOMIC_BOOL_LOCK_FREE 1
> #define __GCC_ATOMIC_POINTER_LOCK_FREE 1
> #define __GCC_ATOMIC_INT_LOCK_FREE 1
> #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
> #define __GCC_ATOMIC_LONG_LOCK_FREE 1
> #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
> #define __GCC_ATOMIC_LLONG_LOCK_FREE 1
> #define __GCC_ATOMIC_SHORT_LOCK_FREE 1
> ARMv5
> #define __GCC_ATOMIC_CHAR_LOCK_FREE 1
> #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
> #define __GCC_ATOMIC_BOOL_LOCK_FREE 1
> #define __GCC_ATOMIC_POINTER_LOCK_FREE 1
> #define __GCC_ATOMIC_INT_LOCK_FREE 1
> #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
> #define __GCC_ATOMIC_LONG_LOCK_FREE 1
> #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
> #define __GCC_ATOMIC_LLONG_LOCK_FREE 1
> #define __GCC_ATOMIC_SHORT_LOCK_FREE 1
> ARMv6
> #define __GCC_ATOMIC_CHAR_LOCK_FREE 1
> #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
> #define __GCC_ATOMIC_BOOL_LOCK_FREE 1
> #define __GCC_ATOMIC_POINTER_LOCK_FREE 2
> #define __GCC_ATOMIC_INT_LOCK_FREE 2
> #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
> #define __GCC_ATOMIC_LONG_LOCK_FREE 2
> #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
> #define __GCC_ATOMIC_LLONG_LOCK_FREE 1
> #define __GCC_ATOMIC_SHORT_LOCK_FREE 1
> ARMv7-a
> #define __GCC_ATOMIC_CHAR_LOCK_FREE 2
> #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
> #define __GCC_ATOMIC_BOOL_LOCK_FREE 2
> #define __GCC_ATOMIC_POINTER_LOCK_FREE 2
> #define __GCC_ATOMIC_INT_LOCK_FREE 2
> #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
> #define __GCC_ATOMIC_LONG_LOCK_FREE 2
> #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2
> #define __GCC_ATOMIC_LLONG_LOCK_FREE 2
> #define __GCC_ATOMIC_SHORT_LOCK_FREE 2

What you're actually showing is that even for ARMv4 they are
sometimes lock free by using the kernel support.

> There are kernel helpers available to provide some atomic support, but
> they'll be very slow compared to real hardware support at this level.

I was under the impression that that's not the case:
https://lwn.net/Articles/314561/


Kurt


Reply to: