From: Zhao Zhili <zhiliz...@tencent.com>
---
The code can be simplified by always creating mutex/cond. I'm not sure
it worth the overhead. Please note !HAVE_THREADS don't have the same
problem since it has mock implementation of ff_mutex_lock/unlock.
libavutil/executor.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavutil/executor.c b/libavutil/executor.c
index fb20104b58..89058fab2f 100644
--- a/libavutil/executor.c
+++ b/libavutil/executor.c
@@ -194,14 +194,17 @@ void av_executor_execute(AVExecutor *e, AVTask *t)
AVTaskCallbacks *cb = &e->cb;
AVTask **prev;
- ff_mutex_lock(&e->lock);
+ if (e->thread_count)
+ ff_mutex_lock(&e->lock);
if (t) {
for (prev = &e->tasks; *prev && cb->priority_higher(*prev, t); prev =
&(*prev)->next)
/* nothing */;
add_task(prev, t);
}
- ff_cond_signal(&e->cond);
- ff_mutex_unlock(&e->lock);
+ if (e->thread_count) {
+ ff_cond_signal(&e->cond);
+ ff_mutex_unlock(&e->lock);
+ }
if (!e->thread_count || !HAVE_THREADS) {
// We are running in a single-threaded environment, so we must handle
all tasks ourselves
--
2.42.0
_______________________________________________
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".
