summaryrefslogtreecommitdiffstats
path: root/src/pulsecore/memblockq.h
diff options
context:
space:
mode:
authorLennart Poettering <lennart@poettering.net>2006-09-08 15:43:44 +0000
committerLennart Poettering <lennart@poettering.net>2006-09-08 15:43:44 +0000
commitbfaa3584581c0d9f3acc7208a0d7ab13845124ab (patch)
treeb2f2b977224f2f6eb75ef99abbbb2bd00a619b5b /src/pulsecore/memblockq.h
parent791bbd8e0e8b0a2350ee20321578f34ca026cd0e (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/memblockq.h')
0 files changed, 0 insertions, 0 deletions