FFmpeg

Commit Graph

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>	1 year ago
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>	3 years ago
Anton Khirnov	90eef1c3de	lavu/threadmessage: switch to new FIFO API	3 years ago
Clément Bœsch	71fa82bed6	lavu/threadmessage: add av_thread_message_queue_nb_elems()	7 years ago
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>	8 years ago
Clément Bœsch	a8bb81a05c	lavc, lavu: use avutil/thread.h instead of redundant conditional includes	9 years ago
Clément Bœsch	5e0c47d41c	avutil/threadmessage: fix build without HAVE_THREADS, new attempt	9 years ago
Clément Bœsch	d4b1b33e69	avutil/threadmessage: fix build without HAVE_THREADS	9 years ago
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.	9 years ago
Clément Bœsch	f98abe0ee7	avutil/threadmessage: add av_thread_message_flush()	9 years ago
Nicolas George	55cc60cd6d	lavu: add thread message API.	11 years ago

11 Commits (cfbb6e9f5d8a55ab3a6be28fada54f4717698974)