[vlc-devel] [RFC PATCH 0/3] decoder: mutexes and conds cleanup

Rémi Denis-Courmont remi at remlab.net
Wed Apr 1 17:41:42 CEST 2015


Le mercredi 01 avril 2015, 16:13:15 Thomas Guillem a écrit :
> I have been trying to fix a race when the input wait for the decoder that
> has not decoded any data yet and won't decode anything. See mail "[PATCH]
> decoder: fix race".
> 
> My biggest issue was that the function input_DecoderWait waited for 2
> different variables protected by 2 different mutexes and signaled by 2
> different cond. So I decided to minimize the number of mutexes and conds.

Your "biggest issue" does not exist... input_DecoderWait() only waits on 
wait_acknowledge (#L2140).

> Now, in decoder.c, the input Fifo and the DecoderThread share the same mutex
> and the same cond.

It should be possible to merge wait_acknowledge and wait_fifo, while moving the 
corresponding state from the owner lock to the FIFO lock. But I don't think 
that suppressing the owner lock completely is a good idea. And in any case, we 
need at the very least two condition variables (one in each direction), from 
the four that currently exist.

> I had to move some long function call (the ones calling
> aout/vout) outside the lock in order to don't block or wait too long while
> the mutex is locked.

The main point of my most recent changes were to move aout_DecPlay() out of 
the (owner) lock. But to do that, I have to remove all accesses to p_aout 
outside the lock. And to do that, I have to remove all accesses to p_aout from 
outside the decoder thread. I think I managed to remove aout_DecIsEmpty(), but 
I still have some challenges with aout_DecChangePause().

tl;dr: you cannot do that so easily.

-- 
Rémi Denis-Courmont
http://www.remlab.net/




More information about the vlc-devel mailing list