diff options
author | Lennart Poettering <lennart@poettering.net> | 2006-09-08 15:43:44 +0000 |
---|---|---|
committer | Lennart Poettering <lennart@poettering.net> | 2006-09-08 15:43:44 +0000 |
commit | bfaa3584581c0d9f3acc7208a0d7ab13845124ab (patch) | |
tree | b2f2b977224f2f6eb75ef99abbbb2bd00a619b5b /src/pulsecore/sink.h | |
parent | 791bbd8e0e8b0a2350ee20321578f34ca026cd0e (diff) |
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
Diffstat (limited to 'src/pulsecore/sink.h')
0 files changed, 0 insertions, 0 deletions