[pulseaudio-discuss] deadlocks when running pulseaudio with --high-priority=1

[Kai.Vehmanen at nokia.com]

Hello all,

this is probably a known issue, but I'm constantly hitting 
a deadlock when running Pulseaudio (0.9.7) with SCHED_FIFO
(--high-priority=1). 

I can reproduce it as follows:

- run pulseaudio (self-compiled, debian stable) with --high-priority=1
- first client: while [ 1 ] ; do aplay -D pulse foo.wav ; done
- second: while [ 1 ] ; do aplay -D pulse foo.wav ; done

At some point, pulseaudio gets stuck and backtrace shows its
stuck in memblock.c:pa_memblock_unref() -> memblock_free() 
-> pa_mutex_lock().

There's a FIXME comment already in the function, so I guess this
is known. 

I made a fix in my local tree which uses pa_mutex_trylock() (a new
funtion implemented using pthread_mutex_trylock()) and nanosleep() 
to avoid the priority inversion (spins until it gets the lock).
With this patch, Pulseaudio now survices the above stresstest.
Of course, nanosleeping() in RT context is very, very ugly, 
but better than a deadlock, at least. ;)

Any ideas how to go forward? I could clean up the code and send
a patch, or alternatively try out a different approach. I don't
fully grok all the code in memblock_free() yet, so it's hard to
say how big of a task it would be to make this totally lock-free.
At least doesn't look to be very straighforward...

br,
-- 
first.surname at nokia.com (Kai Vehmanen)