1. 07 Dec, 2015 5 commits
    • Clément Bœsch's avatar
    • Clément Bœsch's avatar
    • Clément Bœsch's avatar
      d4b1b33e
    • Clément Bœsch's avatar
      avutil/threadmessage: split the pthread condition in two · bd5c860f
      Clément Bœsch authored
      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.
      bd5c860f
    • Clément Bœsch's avatar
      f98abe0e
  2. 26 May, 2014 1 commit