[FFmpeg-devel] [PATCH 35/42] avcodec/threadprogress: Add new API for frame-threaded progress

[Andreas Rheinhardt]

Michael Niedermayer:
> On Tue, Sep 19, 2023 at 09:57:27PM +0200, Andreas Rheinhardt wrote:
>> The API is very similar by the ProgressFrame API, with the exception
>> that it no longer has an included AVFrame. Instead one can wait
>> on anything via a ThreadProgress. One just has to ensure that
>> the lifetime of the object containing the ThreadProgress is long
>> enough (the corresponding problem for ProgressFrames is solved
>> by allocating the progress and giving each thread a reference
>> to it). This will typically be solved by putting a ThreadProgress
>> in a refcounted structure that is shared between threads.
>> It will be put to the test in the following commits.
>>
>> An alternative to the check for whether the owner exists
>> (meaning "do we use frame-threading?") would be to initialize
>> the progress to INT_MAX in case frame threading is not in use.
>> This would probably be preferable on arches where atomic reads
>> are cheap (like x86), but are there ones where it is not?
>>
>> One could also (guarded by e.g. an ASSERT_LEVEL check) actually
>> track the progress for non-framethreading, too, in order to
>> track errors even in single-threaded mode.
>>
>> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt at outlook.com>
>> ---
>>  libavcodec/pthread_frame.c  | 50 +++++++++++++++++++++++++++++++++++++
>>  libavcodec/threadprogress.h | 37 +++++++++++++++++++++++++++
>>  2 files changed, 87 insertions(+)
>>  create mode 100644 libavcodec/threadprogress.h
> 
> Seems to break build here with shared libs / clang
> 
> CC	libavcodec/pthread_frame.o
> src/libavcodec/pthread_frame.c:1108:9: error: address argument to atomic operation must be a pointer to non-const _Atomic type ('const atomic_int *' (aka 'const _Atomic(int) *') invalid)
>         atomic_load_explicit(&pro->progress, memory_order_acquire) >= n)
>         ^                    ~~~~~~~~~~~~~~
> /usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:135:30: note: expanded from macro 'atomic_load_explicit'
> #define atomic_load_explicit __c11_atomic_load
>                              ^
> src/libavcodec/pthread_frame.c:1116:12: error: address argument to atomic operation must be a pointer to non-const _Atomic type ('const atomic_int *' (aka 'const _Atomic(int) *') invalid)
>     while (atomic_load_explicit(&pro->progress, memory_order_relaxed) < n)
>            ^                    ~~~~~~~~~~~~~~
> /usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:135:30: note: expanded from macro 'atomic_load_explicit'
> #define atomic_load_explicit __c11_atomic_load
>                              ^
> 2 errors generated.
> src/ffbuild/common.mak:81: recipe for target 'libavcodec/pthread_frame.o' failed
> make: *** [libavcodec/pthread_frame.o] Error 1
> make: Target 'all' not remade because of errors.
> 

The original version of C11 did not allow to use atomic_load() on
const-qualified atomic objects (presumably because on systems that don't
have native support for atomic operations this might involve locking a
mutex or so and this would involve writes); this has since been changed
(see defect report N1807), yet your (presumably) ancient toolchain does
not reflect that.

I'll cast const away here and add a comment.

- Andreas