1<html><body><pre>ANDROID ATOMICS OPERATIONS 2 3The problem: 4============ 5 6If your application native code was generated with a NDK release older than r7b 7and uses any of the following functions defined in the <sys/atomics.h> 8header: 9 10 __atomic_cmpxchg 11 __atomic_inc 12 __atomic_dec 13 __atomic_swap 14 15Then the corresponding machine code is not guaranteed to work properly on 16some multi-core Android ARM-based devices (x86 ones are not affected). 17 18The solution: 19============= 20 21The <sys/atomics.h> header has been updated in NDK r7b. Simply recompiling 22your _unmodified_ sources with this version of the NDK should be enough to 23completely eliminate the problem. 24 25If you can't use NDK r7b or later for some reason, read the section below. 26 27More details: 28============= 29 30The main issue is that the implementation of these functions, as provided 31by the C library, did not provide any associated memory barriers. This is 32by design, because the platform code that uses them does insert explicit 33barriers around these operations. 34 35The functions were only exposed through the NDK by mistake, they were not 36supposed to be used from applications. Any application code that use them 37without inserting its own barriers may experiment incorrect behaviour, 38which can result in bugs that are very hard to reproduce and diagnose. 39 40Not all multi-core devices are affected though. Certain OEMs enforce a 41policy where all threads of a single process are forced to run on the same 42core. In this case, the bug cannot occur, unless you're directly accessing 43shared memory between two processes. 44 45The problem is only likely to be seen on devices running Android 3.0 to 46Android 4.1. The C library implementation in 4.1 has been updated to provide 47full memory barriers as well. This ensures existing native code keeps 48working correctly on this platform and future ones, even if they were not 49recompiled. 50 51We still strongly recommend recompiling your native code to ensure you'll 52never have to debug this issue (life is short). In the case where this would 53not be possible (e.g. you're using an older version of the NDK for some 54reason, or a custom build system / toolchain), we recommend stopping from 55using these functions entirely. Very fortunately, GCC provides handy 56intrinsics functions that work with very reasonable performance and always 57provide a full barrier. 58 59 __sync_fetch_and_add instead of __atomic_inc 60 __sync_fetch_and_sub instead of __atomic_sub 61 __sync_val_compare_and_swap instead of __atomic_cmpxchg 62 63See the content of platforms/android-3/arch-arm/usr/include/sys/atomics.h 64to see how these can be used. 65 66See the following URL for more GCC-related information: 67 68 http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html 69 70</pre></body></html> 71