1
0
mirror of https://github.com/FFmpeg/FFmpeg.git synced 2024-11-21 10:55:51 +02:00
Commit Graph

11 Commits

Author SHA1 Message Date
Andreas Rheinhardt
e3b355c0be avutil/mem: Don't include avutil.h
It is not necessary at all. So remove it.
This also breaks an inclusion cycle mem.h->avutil.h->common.h->mem.h.

Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2023-09-07 00:42:10 +02:00
Andreas Rheinhardt
0a1a8fcd56 avutil/fifo: Don't include avutil.h
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2022-02-24 12:56:49 +01:00
Anton Khirnov
90eef1c3de lavu/threadmessage: switch to new FIFO API 2022-02-07 00:31:23 +01:00
Clément Bœsch
71fa82bed6 lavu/threadmessage: add av_thread_message_queue_nb_elems() 2018-04-26 19:41:19 +02:00
Aleksandr Slobodeniuk
390e028c66 avutil/threadmessage: fix error return in case of av_fifo_alloc failure
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
2017-07-14 02:30:37 +02:00
Clément Bœsch
a8bb81a05c lavc, lavu: use avutil/thread.h instead of redundant conditional includes 2015-12-07 17:25:51 +01:00
Clément Bœsch
5e0c47d41c avutil/threadmessage: fix build without HAVE_THREADS, new attempt 2015-12-07 16:39:57 +01:00
Clément Bœsch
d4b1b33e69 avutil/threadmessage: fix build without HAVE_THREADS 2015-12-07 14:28:34 +01:00
Clément Bœsch
bd5c860fdb avutil/threadmessage: split the pthread condition in two
Fix a dead lock under certain conditions. Let's assume we have a queue of 1
message max, 2 senders, and 1 receiver.

Scenario (real record obtained with debug added):
    [...]
    SENDER #0: acquired lock
    SENDER #0: queue is full, wait
    SENDER #1: acquired lock
    SENDER #1: queue is full, wait
    RECEIVER: acquired lock
    RECEIVER: reading a msg from the queue
    RECEIVER: signal the cond
    RECEIVER: acquired lock
    RECEIVER: queue is empty, wait
    SENDER #0: writing a msg the queue
    SENDER #0: signal the cond
    SENDER #0: acquired lock
    SENDER #0: queue is full, wait
    SENDER #1: queue is full, wait

Translated:
 - initially the queue contains 1/1 message with 2 senders blocking on
   it, waiting to push another message.
 - Meanwhile the receiver is obtaining the lock, read the message,
   signal & release the lock. For some reason it is able to acquire the
   lock again before the signal wakes up one of the sender. Since it
   just emptied the queue, the reader waits for the queue to fill up
   again.
 - The signal finally reaches one of the sender, which writes a message
   and then signal the condition. Unfortunately, instead of waking up
   the reader, it actually wakes up the other worker (signal = notify
   the condition just for 1 waiter), who can't push another message in
   the queue because it's full.
 - Meanwhile, the receiver is still waiting. Deadlock.

This scenario can be triggered with for example:
    tests/api/api-threadmessage-test 1 2 100 100 1 1000 1000

One working solution is to make av_thread_message_queue_{send,recv}()
call pthread_cond_broadcast() instead of pthread_cond_signal() so both
senders and receivers are unlocked when work is done (be it reading or
writing).

This second solution replaces the condition with two: one to notify the
senders, and one to notify the receivers. This prevents senders from
notifying other senders instead of a reader, and the other way around.
It also avoid broadcasting to everyone like the first solution, and is,
as a result in theory more optimized.
2015-12-07 11:39:28 +01:00
Clément Bœsch
f98abe0ee7 avutil/threadmessage: add av_thread_message_flush() 2015-12-07 11:39:28 +01:00
Nicolas George
55cc60cd6d lavu: add thread message API. 2014-05-26 11:40:15 +02:00