RepoMirrors/mpv
1
0
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2024-12-27 01:22:30 +00:00
Code Issues Releases Wiki Activity
e955ae9000
mpv/osdep/atomics.h

90 lines
3.0 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>
*
Relicense some non-MPlayer source files to LGPL 2.1 or later This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
2016-01-19 17:36:06 +00:00
* mpv is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
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
*
* 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
Relicense some non-MPlayer source files to LGPL 2.1 or later This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
2016-01-19 17:36:06 +00:00
* GNU Lesser General Public License for more details.
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
*
Relicense some non-MPlayer source files to LGPL 2.1 or later This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
2016-01-19 17:36:06 +00:00
* You should have received a copy of the GNU Lesser General Public
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
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
#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.
build: always require atomics Always require them, instead of just for some components which have hard requirements on correct atomic semantics. They should be widely available, and are supported by all recent gcc and clang compiler versions. We even have the fallbacks builtins, which should keep this working on very old gcc releases. In particular, w32_common.c recently added a hard requirement on atomics, but checking this properly in the build system would have been messy. This commit makes sure it always works. The fallback where weak atomic semantics are always fine is in theory rather questionable as well.
2016-08-05 15:10:22 +00:00
typedef struct { volatile unsigned long v; } atomic_ulong;
typedef struct { volatile int v; } atomic_int;
typedef struct { volatile unsigned int v; } atomic_uint;
typedef struct { volatile _Bool v; } atomic_bool;
typedef struct { volatile long long v; } atomic_llong;
typedef struct { volatile uint_least32_t v; } atomic_uint_least32_t;
typedef struct { volatile unsigned long long v; } 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: always require atomics Always require them, instead of just for some components which have hard requirements on correct atomic semantics. They should be widely available, and are supported by all recent gcc and clang compiler versions. We even have the fallbacks builtins, which should keep this working on very old gcc releases. In particular, w32_common.c recently added a hard requirement on atomics, but checking this properly in the build system would have been messy. This commit makes sure it always works. The fallback where weak atomic semantics are always fine is in theory rather questionable as well.
2016-08-05 15:10:22 +00:00
# error "this should have been a configuration error, report a bug please"
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