[pulseaudio-tickets] [PulseAudio] #195: possible deadlocks when running pulseaudio with --high-priority=1

[PulseAudio]

#195: possible deadlocks when running pulseaudio with --high-priority=1
--------------------------+-------------------------------------------------
  Reporter:  kaivehmanen  |       Owner:  lennart   
      Type:  defect       |      Status:  new       
  Priority:  normal       |   Milestone:            
 Component:  core         |    Severity:  normal    
Resolution:               |    Keywords:  SCHED_FIFO
--------------------------+-------------------------------------------------
Comment (by kaivehmanen):

 The traced run was on armv6. I remember reproducing this on x86 as well,
 but now when I tried it again, I couldn't trigger it anymore. :( And even
 on armv6, you have to create quite a bit of load (including constant
 addition/removals of clients) to trigger the freeze. Anyways, looking at
 the traces, this doesn't seem to be same as #178, but the two can still be
 related. Currently I've been able to workaround this bug by using
 trylock() variant in the real-time thread (i.e. don't take the lock if
 lower-priority bug is holding it). While this is not an acceptable
 solution, this does suggest that the bug is indeed in PRIO_INHERIT. On the
 other hand, the lower priority thread (in above trace) is blocked in
 sem_wait() and raising its priority doesn't really help so this could
 still be something else as well.

 Oh well, more details are obviously needed. If/when I have a free time
 slot, I'll try to dig deeper and see who/where is actually taking the
 memblock mutex that ends up blocking the high-priority thread. I'm ok with
 closing the ticket for now as duplicate of 178 (I'll reopen if I can prove
 it's not PRIO_INHERIT).

-- 
Ticket URL: <http://pulseaudio.org/ticket/195#comment:4>
PulseAudio <http://pulseaudio.org/>
The PulseAudio Sound Server