Can bionic/libc/include/sys/atomics.h be used for atomic operations?

[Sushmita]

Hi,

I understand that this group is only for issues related to the ndk.
I'm posting this question to this group because I saw a very similar
thread on this group and wanted some clarifications.

I need to use atomic increment, decrement, swap and cmpxchg
instructions in android userspace. I found 2 implementations for
these:

a) bionic/libc/include/sys/atomics.h
b) system/core/include/cutils/atomic.h

My questions are:

1) Can a) be used for implementing atomic operations in userspace? If
not, why?
2) If I use b), what is the equivalent of the gcc built-in
sync_lock_test_and_set (atomic exchange) instruction in b)?
3) What is the difference between the two implementations a) and b)?
When should we use which?

I'm not using the ndk toolchain, but the standard android toolchain.

Thanks,
Sushmita

[David Turner]

On Thu, Dec 8, 2011 at 2:17 AM, Sushmita <ssus...@codeaurora.org> wrote:

Hi,

I understand that this group is only for issues related to the ndk.
I'm posting this question to this group because I saw a very similar
thread on this group and wanted some clarifications.

I need to use atomic increment, decrement, swap and cmpxchg
instructions in android userspace. I found 2 implementations for
these:

a) bionic/libc/include/sys/atomics.h
b) system/core/include/cutils/atomic.h

My questions are:

1) Can a) be used for implementing atomic operations in userspace? If
not, why?

a) was not supported to be used by application code (it's a C library implementation detail). The implementation is correct except that it never uses memory barriers, so calling these functions on multi-core devices will be problematic. This is not a problem in the C library, because the code that uses them does use explicit memory barriers before/after them.

 

b) is reserved for platform code only (i.e. do not use it in applications). That's because when building for the platform, you do know the exact details of the target device, e.g. whether it's a single-core or multi-core CPU (in the first case, you can remove all memory barrier operations safely, not in the second). They are perfectly ok if you're building platform code.

When generating application code, you don't know on which kind of CPU you're going to run, and running the hardware memory operation (e.g. "dmb" instruction) can be _very_ costly (e.g. 180ns on a Nexus One) and will get you crap performance.

2) If I use b), what is the equivalent of the gcc built-in
sync_lock_test_and_set (atomic exchange) instruction in b)?

See attached file, which will be the version of <sys/atomics.h> that will come with the next NDK release

All gcc builtins provide full memory barriers and thus are safe to use. Performance is relatively good though it's possible to do a bit better with a lot of effort (I hope to provide something for this later).

 

3) What is the difference between the two implementations a) and b)?
When should we use which?

Hope this was answered in 1. You should use GCC builtins for now for applications. If you are using platform code, use the functions in <cutils/atomic.h>

 

I'm not using the ndk toolchain, but the standard android toolchain.

 

Thanks,
Sushmita

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[ssus...@codeaurora.org]

Thanks a lot for the information!

-Sushmita

[Ratamovic]

Thanks a lot. That's really useful stuff!

[Gregory Pakosz]

Regarding GCC built-ins.
I just installed ndk-r7 and GCC doesn't define
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 or
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8.
Will the next ndk provide that?
Regards,Gregory

On Dec 13, 10:44 am, Ratamovic <ratamo...@gmail.com> wrote:
> Thanks a lot. That's really useful stuff!
>
> On Dec 13, 2:01 am, ssush...@codeaurora.org wrote:
>
>
>
>
>
>
>
> > Thanks a lot for the information!
>
> > -Sushmita
>
> > > On Thu, Dec 8, 2011 at 2:17 AM, Sushmita <ssush...@codeaurora.org> wrote:
>
> > >> Hi,
>
> > >> I understand that this group is only for issues related to the ndk.
> > >> I'm posting this question to this group because I saw a very similar
> > >> thread on this group and wanted some clarifications.
>

> > >> I need to useatomicincrement, decrement, swap and cmpxchg

> > >> instructions in android userspace. I found 2 implementations for
> > >> these:
>
> > >> a) bionic/libc/include/sys/atomics.h
> > >> b) system/core/include/cutils/atomic.h
>
> > >> My questions are:
>

> > >> 1) Can a) be used for implementingatomicoperations in userspace? If

> > >> not, why?
>
> > > a) was not supported to be used by application code (it's a C library
> > > implementation detail). The implementation is correct except that it never
> > > uses memory barriers, so calling these functions on multi-core devices
> > > will
> > > be problematic. This is not a problem in the C library, because the code
> > > that uses them does use explicit memory barriers before/after them.
>
> > > b) is reserved for platform code only (i.e. do not use it in
> > > applications).
> > > That's because when building for the platform, you do know the exact
> > > details of the target device, e.g. whether it's a single-core or
> > > multi-core
> > > CPU (in the first case, you can remove all memory barrier operations
> > > safely, not in the second). They are perfectly ok if you're building
> > > platform code.
>
> > > When generating application code, you don't know on which kind of CPU
> > > you're going to run, and running the hardware memory operation (e.g. "dmb"
> > > instruction) can be _very_ costly (e.g. 180ns on a Nexus One) and will get
> > > you crap performance.
>
> > > 2) If I use b), what is the equivalent of the gcc built-in

> > >> sync_lock_test_and_set (atomicexchange) instruction in b)?

[David Turner]

Maybe the macros are not defined, but the intrinsics *definitely* work with the NDK r7 toolchain.

Do you have a problem with them?

[Gregory Pakosz]

Hello David,
Thank you for the quick reply. No problem with built-ins, indeed it
definitely works with NDK r7; it's just our preprocessor logic was
based on GCC macros being defined and in case of Android I was using
__atomic_cmpxchg but I'm now using __sync_bool_compare_and_swap.
It indeed runs fine on devices.
Regards,Gregory

On Dec 15, 3:22 pm, David Turner <di...@android.com> wrote:
> Maybe the macros are not defined, but the intrinsics *definitely* work with
> the NDK r7 toolchain.
> Do you have a problem with them?
>