summaryrefslogtreecommitdiff
path: root/libavutil/threadmessage.c
Commit message (Collapse)AuthorAgeFilesLines
* avutil/fifo: Don't include avutil.hAndreas Rheinhardt2022-02-241-0/+2
| | | | | Reviewed-by: Martin Storsjö <martin@martin.st> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* lavu/threadmessage: switch to new FIFO APIAnton Khirnov2022-02-071-19/+19
|
* lavu/threadmessage: add av_thread_message_queue_nb_elems()Clément Bœsch2018-04-261-0/+13
|
* avutil/threadmessage: fix error return in case of av_fifo_alloc failureAleksandr Slobodeniuk2017-07-141-1/+1
| | | | | Reviewed-by: Nicolas George <george@nsup.org> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* lavc, lavu: use avutil/thread.h instead of redundant conditional includesClément Bœsch2015-12-071-11/+1
|
* avutil/threadmessage: fix build without HAVE_THREADS, new attemptClément Bœsch2015-12-071-0/+2
|
* avutil/threadmessage: fix build without HAVE_THREADSClément Bœsch2015-12-071-0/+2
|
* avutil/threadmessage: split the pthread condition in twoClément Bœsch2015-12-071-11/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* avutil/threadmessage: add av_thread_message_flush()Clément Bœsch2015-12-071-0/+31
|
* lavu: add thread message API.Nicolas George2014-05-261-0/+184