On 5/31/2021 5:09 AM, Anton Khirnov wrote:
Quoting James Almer (2021-05-23 00:09:02)
This is in preparation for the following commit.
Signed-off-by: James Almer <jamr...@gmail.com>
---
libavutil/mem.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/libavutil/mem.c b/libavutil/mem.c
index fa227f5e12..c12c24aa90 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -31,6 +31,7 @@
#include <limits.h>
#include <stdint.h>
#include <stdlib.h>
+#include <stdatomic.h>
#include <string.h>
#if HAVE_MALLOC_H
#include <malloc.h>
@@ -68,17 +69,17 @@ void free(void *ptr);
* dynamic libraries and remove -Wl,-Bsymbolic from the linker flags.
* Note that this will cost performance. */
-static size_t max_alloc_size= INT_MAX;
+static atomic_size_t max_alloc_size = ATOMIC_VAR_INIT(INT_MAX);
void av_max_alloc(size_t max){
- max_alloc_size = max;
+ atomic_store_explicit(&max_alloc_size, max, memory_order_relaxed);
Any specific reason for using a non-default memory order?
AFAIK it is recommended by the spec authors to use default (sequentially
consistent) operations unless there is a very good reason to do
something else.
I copied the existing behavior of av_force_cpu_flags() and
av_get_cpu_flags(), which seems to be enough for a similar atomic
variable as max_alloc_size.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
