RepoMirrors/mpv
1
0
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2024-12-21 14:22:17 +00:00
Code Issues Releases Wiki Activity
e9822f6012
mpv/osdep/atomics.h

103 lines
3.6 KiB
C
Raw Normal View History

core: add a spsc ringbuffer implementation Currently every single AO was implementing it's own ringbuffer, many times with slightly different semantics. This is an attempt to fix the problem. I stole some good ideas from ao_portaudio's ringbuffer and went from there. The main difference is this one stores wpos and rpos which are absolute positions in an "infinite" buffer. To find the actual position for writing / reading just apply modulo size. The producer only modifies wpos while the consumer only modifies rpos. This makes it pretty easy to reason about and make the operations thread safe by using barriers (thread safety is guaranteed only in the Single-Producer/Single- Consumer case). Also adapted ao_coreaudio to use this ringbuffer.
2013-05-23 19:23:32 +00:00
/*
* This file is part of mpv.
* Copyright (c) 2013 Stefano Pigozzi <stefano.pigozzi@gmail.com>
*
* mpv is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* mpv is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with mpv. If not, see <http://www.gnu.org/licenses/>.
*/
atomics: switch to C11 stdatomic.h In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
2014-05-20 23:04:47 +00:00
#ifndef MP_ATOMICS_H
#define MP_ATOMICS_H
core: add a spsc ringbuffer implementation Currently every single AO was implementing it's own ringbuffer, many times with slightly different semantics. This is an attempt to fix the problem. I stole some good ideas from ao_portaudio's ringbuffer and went from there. The main difference is this one stores wpos and rpos which are absolute positions in an "infinite" buffer. To find the actual position for writing / reading just apply modulo size. The producer only modifies wpos while the consumer only modifies rpos. This makes it pretty easy to reason about and make the operations thread safe by using barriers (thread safety is guaranteed only in the Single-Producer/Single- Consumer case). Also adapted ao_coreaudio to use this ringbuffer.
2013-05-23 19:23:32 +00:00
atomics: switch to C11 stdatomic.h In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
2014-05-20 23:04:47 +00:00
#include <inttypes.h>
compat: use __atomic operations instead of __sync, when present Fixes #434 Fixes #437
2013-12-30 15:33:50 +00:00
#include "config.h"
atomics: switch to C11 stdatomic.h In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
2014-05-20 23:04:47 +00:00
#if HAVE_STDATOMIC
#include <stdatomic.h>
#else
// Emulate the parts of C11 stdatomic.h needed by mpv.
// Still relies on gcc/clang atomic builtins.
atomics: add atomic_fetch_and/atomic_fetch_or As usual, we prefer plain C11 names and semantics, and have to emulate them if C11 atomics are not available. For the non-atomic fallback (which is just there to make code compile in situations the atomic property is not overly important), we require a gross hack to make the generic macros work without using compiler- specific extensions.
2015-05-11 21:20:45 +00:00
// The t field is a hack to make the non-atomic fallback macro mess work.
atomics: switch to C11 stdatomic.h In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
2014-05-20 23:04:47 +00:00
atomics: add atomic_fetch_and/atomic_fetch_or As usual, we prefer plain C11 names and semantics, and have to emulate them if C11 atomics are not available. For the non-atomic fallback (which is just there to make code compile in situations the atomic property is not overly important), we require a gross hack to make the generic macros work without using compiler- specific extensions.
2015-05-11 21:20:45 +00:00
typedef struct { volatile unsigned long v, t; } atomic_ulong;
typedef struct { volatile int v, t; } atomic_int;
ao: make better use of atomics The main reason for this was compatibility; but some associated problems have been solved in the previous commit.
2015-05-11 21:27:41 +00:00
typedef struct { volatile unsigned int v, t; } atomic_uint;
atomics: add atomic_fetch_and/atomic_fetch_or As usual, we prefer plain C11 names and semantics, and have to emulate them if C11 atomics are not available. For the non-atomic fallback (which is just there to make code compile in situations the atomic property is not overly important), we require a gross hack to make the generic macros work without using compiler- specific extensions.
2015-05-11 21:20:45 +00:00
typedef struct { volatile _Bool v, t; } atomic_bool;
typedef struct { volatile long long v, t; } atomic_llong;
typedef struct { volatile uint_least32_t v, t; } atomic_uint_least32_t;
typedef struct { volatile unsigned long long v, t; } atomic_ullong;
atomics: switch to C11 stdatomic.h In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
2014-05-20 23:04:47 +00:00
#define ATOMIC_VAR_INIT(x) \
{.v = (x)}
atomics: more correct usage of gcc/clang __atomic builtins This should be more correct. The builtins were made to directly map to C11, and the way we use them is now relatively close to how gcc implements atomics in 4.9. In particular, we make use of the load and store builtins. I'm not entirely sure why gcc didn't support stdatomic.h in 4.8 already. Maybe support for the builtins was incomplete or broken - so there's a lot of room for doubt about the correctness of this.
2014-05-20 23:27:54 +00:00
msg: use relaxed atomics for log level test This should be sufficient. If stdatomic.h is not available, we make no difference.
2015-03-02 18:09:31 +00:00
#define memory_order_relaxed 1
#define memory_order_seq_cst 2
#define atomic_load_explicit(p, e) atomic_load(p)
atomics: more correct usage of gcc/clang __atomic builtins This should be more correct. The builtins were made to directly map to C11, and the way we use them is now relatively close to how gcc implements atomics in 4.9. In particular, we make use of the load and store builtins. I'm not entirely sure why gcc didn't support stdatomic.h in 4.8 already. Maybe support for the builtins was incomplete or broken - so there's a lot of room for doubt about the correctness of this.
2014-05-20 23:27:54 +00:00
#if HAVE_ATOMIC_BUILTINS
atomics: switch to C11 stdatomic.h In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
2014-05-20 23:04:47 +00:00
#define atomic_load(p) \
atomics: more correct usage of gcc/clang __atomic builtins This should be more correct. The builtins were made to directly map to C11, and the way we use them is now relatively close to how gcc implements atomics in 4.9. In particular, we make use of the load and store builtins. I'm not entirely sure why gcc didn't support stdatomic.h in 4.8 already. Maybe support for the builtins was incomplete or broken - so there's a lot of room for doubt about the correctness of this.
2014-05-20 23:27:54 +00:00
__atomic_load_n(&(p)->v, __ATOMIC_SEQ_CST)
atomics: switch to C11 stdatomic.h In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
2014-05-20 23:04:47 +00:00
#define atomic_store(p, val) \
atomics: more correct usage of gcc/clang __atomic builtins This should be more correct. The builtins were made to directly map to C11, and the way we use them is now relatively close to how gcc implements atomics in 4.9. In particular, we make use of the load and store builtins. I'm not entirely sure why gcc didn't support stdatomic.h in 4.8 already. Maybe support for the builtins was incomplete or broken - so there's a lot of room for doubt about the correctness of this.
2014-05-20 23:27:54 +00:00
__atomic_store_n(&(p)->v, val, __ATOMIC_SEQ_CST)
#define atomic_fetch_add(a, b) \
__atomic_fetch_add(&(a)->v, b, __ATOMIC_SEQ_CST)
atomics: add atomic_fetch_and/atomic_fetch_or As usual, we prefer plain C11 names and semantics, and have to emulate them if C11 atomics are not available. For the non-atomic fallback (which is just there to make code compile in situations the atomic property is not overly important), we require a gross hack to make the generic macros work without using compiler- specific extensions.
2015-05-11 21:20:45 +00:00
#define atomic_fetch_and(a, b) \
__atomic_fetch_and(&(a)->v, b, __ATOMIC_SEQ_CST)
#define atomic_fetch_or(a, b) \
__atomic_fetch_or(&(a)->v, b, __ATOMIC_SEQ_CST)
atomics: add atomic_compare_exchange_strong() As usual, we use C11 semantics, and emulate it if <stdatomic.h> is not available. It's a bit messy with __sync_val_compare_and_swap(). We assume it has "strong" semantics (it can't fail sporadically), but I'm not sure if this is really the case. On the other hand, weak semantics don't seem to be possible, since the builtin can't distinguish between the two failure cases that could occur. Also, to match the C11 interface, use of gcc builtins is unavoidable. Add a check to the build system to make sure the compiler supports them (although I don't think there's any compiler which supports __sync_*, but not these extensions). Needed for the following commit.
2014-11-09 14:12:54 +00:00
#define atomic_compare_exchange_strong(a, b, c) \
__atomic_compare_exchange_n(&(a)->v, b, c, 0, __ATOMIC_SEQ_CST, \
__ATOMIC_SEQ_CST)
atomics: switch to C11 stdatomic.h In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
2014-05-20 23:04:47 +00:00
build: make configure fail if both __atomic and __sync are not available
2014-01-01 19:42:13 +00:00
#elif HAVE_SYNC_BUILTINS
atomics: more correct usage of gcc/clang __atomic builtins This should be more correct. The builtins were made to directly map to C11, and the way we use them is now relatively close to how gcc implements atomics in 4.9. In particular, we make use of the load and store builtins. I'm not entirely sure why gcc didn't support stdatomic.h in 4.8 already. Maybe support for the builtins was incomplete or broken - so there's a lot of room for doubt about the correctness of this.
2014-05-20 23:27:54 +00:00
#define atomic_load(p) \
atomics: some corrections to __sync builtins usage We don't need to combine __sync_add_and_fetch with a memory barrier, since these intrinsics are documented as using a full barrier already. Use __sync_fetch_and_add instead of __sync_add_and_fetch; this gives atomic_fetch_add() the correct return value (although we don't use it). Use __sync_fetch_and_add to emulate atomic_load(). This should enforce the full barrier semantics better. (This trick is stolen from the FreeBSD based stdatomic.h emulation.)
2014-05-28 20:37:37 +00:00
__sync_fetch_and_add(&(p)->v, 0)
atomics: more correct usage of gcc/clang __atomic builtins This should be more correct. The builtins were made to directly map to C11, and the way we use them is now relatively close to how gcc implements atomics in 4.9. In particular, we make use of the load and store builtins. I'm not entirely sure why gcc didn't support stdatomic.h in 4.8 already. Maybe support for the builtins was incomplete or broken - so there's a lot of room for doubt about the correctness of this.
2014-05-20 23:27:54 +00:00
#define atomic_store(p, val) \
atomics: some corrections to __sync builtins usage We don't need to combine __sync_add_and_fetch with a memory barrier, since these intrinsics are documented as using a full barrier already. Use __sync_fetch_and_add instead of __sync_add_and_fetch; this gives atomic_fetch_add() the correct return value (although we don't use it). Use __sync_fetch_and_add to emulate atomic_load(). This should enforce the full barrier semantics better. (This trick is stolen from the FreeBSD based stdatomic.h emulation.)
2014-05-28 20:37:37 +00:00
(__sync_synchronize(), (p)->v = (val), __sync_synchronize())
atomics: more correct usage of gcc/clang __atomic builtins This should be more correct. The builtins were made to directly map to C11, and the way we use them is now relatively close to how gcc implements atomics in 4.9. In particular, we make use of the load and store builtins. I'm not entirely sure why gcc didn't support stdatomic.h in 4.8 already. Maybe support for the builtins was incomplete or broken - so there's a lot of room for doubt about the correctness of this.
2014-05-20 23:27:54 +00:00
#define atomic_fetch_add(a, b) \
atomics: some corrections to __sync builtins usage We don't need to combine __sync_add_and_fetch with a memory barrier, since these intrinsics are documented as using a full barrier already. Use __sync_fetch_and_add instead of __sync_add_and_fetch; this gives atomic_fetch_add() the correct return value (although we don't use it). Use __sync_fetch_and_add to emulate atomic_load(). This should enforce the full barrier semantics better. (This trick is stolen from the FreeBSD based stdatomic.h emulation.)
2014-05-28 20:37:37 +00:00
__sync_fetch_and_add(&(a)->v, b)
atomics: add atomic_fetch_and/atomic_fetch_or As usual, we prefer plain C11 names and semantics, and have to emulate them if C11 atomics are not available. For the non-atomic fallback (which is just there to make code compile in situations the atomic property is not overly important), we require a gross hack to make the generic macros work without using compiler- specific extensions.
2015-05-11 21:20:45 +00:00
#define atomic_fetch_and(a, b) \
__sync_fetch_and_and(&(a)->v, b)
#define atomic_fetch_or(a, b) \
__sync_fetch_and_or(&(a)->v, b)
atomics: add atomic_compare_exchange_strong() As usual, we use C11 semantics, and emulate it if <stdatomic.h> is not available. It's a bit messy with __sync_val_compare_and_swap(). We assume it has "strong" semantics (it can't fail sporadically), but I'm not sure if this is really the case. On the other hand, weak semantics don't seem to be possible, since the builtin can't distinguish between the two failure cases that could occur. Also, to match the C11 interface, use of gcc builtins is unavoidable. Add a check to the build system to make sure the compiler supports them (although I don't think there's any compiler which supports __sync_*, but not these extensions). Needed for the following commit.
2014-11-09 14:12:54 +00:00
// Assumes __sync_val_compare_and_swap is "strong" (using the C11 meaning).
#define atomic_compare_exchange_strong(p, old, new) \
({ __typeof__((p)->v) val_ = __sync_val_compare_and_swap(&(p)->v, *(old), new); \
bool ok_ = val_ == *(old); \
if (!ok_) *(old) = val_; \
ok_; })
atomics: more correct usage of gcc/clang __atomic builtins This should be more correct. The builtins were made to directly map to C11, and the way we use them is now relatively close to how gcc implements atomics in 4.9. In particular, we make use of the load and store builtins. I'm not entirely sure why gcc didn't support stdatomic.h in 4.8 already. Maybe support for the builtins was incomplete or broken - so there's a lot of room for doubt about the correctness of this.
2014-05-20 23:27:54 +00:00
build: make configure fail if both __atomic and __sync are not available
2014-01-01 19:42:13 +00:00
#else
build: allow compilation without any atomics Not all compilers on all platforms have atomics available (even if they could, technically speaking). We don't use atomics that much, only the following things rely on it: 1. the audio pull code, and all audio outputs using it 2. updating global msg levels 3. reading log messages through the client API Just disable 1. and 3. if atomics are not available. For 2., using fake- atomics isn't too bad; at worst, message levels won't properly update under certain situations (but most likely, it will work just fine). This means if atomics are not available, the client API function mpv_request_log_messages() will do nothing. CC: @mpv-player/stable
2014-07-05 15:02:06 +00:00
// This is extremely wrong. The build system actually disables code that has
// a serious dependency on working atomics, so this is barely ok.
#define atomic_load(p) ((p)->v)
#define atomic_store(p, val) ((p)->v = (val))
atomics: add atomic_fetch_and/atomic_fetch_or As usual, we prefer plain C11 names and semantics, and have to emulate them if C11 atomics are not available. For the non-atomic fallback (which is just there to make code compile in situations the atomic property is not overly important), we require a gross hack to make the generic macros work without using compiler- specific extensions.
2015-05-11 21:20:45 +00:00
#define atomic_fetch_op_(a, b, op) \
((a)->t = (a)->v, (a)->v = (a)->v op (b), (a)->t)
#define atomic_fetch_add(a, b) atomic_fetch_op_(a, b, +)
#define atomic_fetch_and(a, b) atomic_fetch_op_(a, b, &)
#define atomic_fetch_or(a, b) atomic_fetch_op_(a, b, |)
atomics: add atomic_compare_exchange_strong() As usual, we use C11 semantics, and emulate it if <stdatomic.h> is not available. It's a bit messy with __sync_val_compare_and_swap(). We assume it has "strong" semantics (it can't fail sporadically), but I'm not sure if this is really the case. On the other hand, weak semantics don't seem to be possible, since the builtin can't distinguish between the two failure cases that could occur. Also, to match the C11 interface, use of gcc builtins is unavoidable. Add a check to the build system to make sure the compiler supports them (although I don't think there's any compiler which supports __sync_*, but not these extensions). Needed for the following commit.
2014-11-09 14:12:54 +00:00
#define atomic_compare_exchange_strong(p, old, new) \
((p)->v == *(old) ? ((p)->v = (new), 1) : (*(old) = (p)->v, 0))
build: allow compilation without any atomics Not all compilers on all platforms have atomics available (even if they could, technically speaking). We don't use atomics that much, only the following things rely on it: 1. the audio pull code, and all audio outputs using it 2. updating global msg levels 3. reading log messages through the client API Just disable 1. and 3. if atomics are not available. For 2., using fake- atomics isn't too bad; at worst, message levels won't properly update under certain situations (but most likely, it will work just fine). This means if atomics are not available, the client API function mpv_request_log_messages() will do nothing. CC: @mpv-player/stable
2014-07-05 15:02:06 +00:00
#endif /* no atomics */
atomics: switch to C11 stdatomic.h In my opinion, we shouldn't use atomics at all, but ok. This switches the mpv code to use C11 stdatomic.h, and for compilers that don't support stdatomic.h yet, we emulate the subset used by mpv using the builtins commonly provided by gcc and clang. This supersedes an earlier similar attempt by Kovensky. That attempt unfortunately relied on a big copypasted freebsd header (which also depended on much more highly compiler-specific functionality, defined reserved symbols, etc.), so it had to be NIH'ed. Some issues: - C11 says default initialization of atomics "produces a valid state", but it's not sure whether the stored value is really 0. But we rely on this. - I'm pretty sure our use of the __atomic... builtins is/was incorrect. We don't use atomic load/store intrinsics, and access stuff directly. - Our wrapper actually does stricter typechecking than the stdatomic.h implementation by gcc 4.9. We make the atomic types incompatible with normal types by wrapping them into structs. (The FreeBSD wrapper does the same.) - I couldn't test on MinGW.
2014-05-20 23:04:47 +00:00
#endif /* else HAVE_STDATOMIC */
#endif
Reference in New Issue Copy Permalink