add a tiny wrapper around libatomic_ops: pa_atomic_int_t and pa_atomit_ptr_t.
authorLennart Poettering <lennart@poettering.net>
Fri, 8 Sep 2006 15:43:44 +0000 (15:43 +0000)
committerLennart Poettering <lennart@poettering.net>
Fri, 8 Sep 2006 15:43:44 +0000 (15:43 +0000)
commitbfaa3584581c0d9f3acc7208a0d7ab13845124ab
treeb2f2b977224f2f6eb75ef99abbbb2bd00a619b5b
parent791bbd8e0e8b0a2350ee20321578f34ca026cd0e
add a tiny wrapper around libatomic_ops: pa_atomic_int_t and pa_atomit_ptr_t.

Reasoning:

This wrapper fixes a few API issues I found with atomic_ops:

 * AO_t is an int, which can be written to with "=". pa_tomic_int_t however is
   a struct which due to type-safety enforces proper access with
   pa_atomic_xx(). (Inspired by the way the Linux kernel handles this)

 * AO_load()'s parameter is lacking a "const"

 * Explicitly choosing the proper memory barrier for each call is very
   difficult and especially hard to debug because most CPUs support only two
   different barrier types which the eight types defined by atomic_ops are
   mapped to. Most other software (i.e. glib, Linux kernel) which provides
   atomic variable access usually do a full barrier in all cases and so should
   we. Eventually we might choose to add additional memory barrier calls, in
   which case we can add special versions of the current function with special
   suffixes.

 * The function names are unnecesarily long

 * Atomic pointer accesses are only supported with manual casts.

The new pa_atomic_xxx interface borrows heavily from the GLib and Linux kernel
atomicity API, though it is different from both of them.

In addition this abstract API makes it easy to port PA to different atomicty
APIs, if libatomic_ops should ever become out-of-fashion or if the system OS
supports atomic primitives anyway.

git-svn-id: file:///home/lennart/svn/public/pulseaudio/trunk@1381 fefdeb5f-60dc-0310-8127-8f9354f1896f
src/pulsecore/atomic.h [new file with mode: 0644]