add a tiny wrapper around libatomic_ops: pa_atomic_int_t and pa_atomit_ptr_t.
commitac353eb559e8b8dc49a1e097207c732304634f01
authorLennart Poettering <lennart@poettering.net>
Fri, 8 Sep 2006 15:43:44 +0000 (8 15:43 +0000)
committerLennart Poettering <lennart@poettering.net>
Fri, 8 Sep 2006 15:43:44 +0000 (8 15:43 +0000)
treeb2f2b977224f2f6eb75ef99abbbb2bd00a619b5b
parentcebf6a0a2451a5fa4bf62587258880902ff2f36d
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: svn://svn.0pointer.net/pulseaudio/trunk@1381 fefdeb5f-60dc-0310-8127-8f9354f1896f
src/pulsecore/atomic.h [new file with mode: 0644]