[alsa-devel] locking looks odd

[Takashi Iwai]

On Tue, 30 Aug 2016 17:54:22 +0200,
Alan Horstmann wrote:
> 
> On Tuesday 30 August 2016 15:20, Takashi Iwai wrote:
> > (Adding Alan to Cc)
> >
> > On Fri, 26 Aug 2016 21:02:12 +0200,
> >
> > Samuel Thibault wrote:
> > > Samuel Thibault, on Sat 20 Aug 2016 14:12:05 +0200, wrote:
> > > > I'd just like to check something: do we agree that libasound must be
> > > > thread-safe by default (otherwise it breaks the application assumption
> > > > that it's thread-safe)?  If so, then there are thread-safety bugs:
> > >
> > > Ok, now with the discussion on the portaudio list starting at
> > >
> > > https://lists.columbia.edu/pipermail/portaudio/2016-August/000599.html
> > >
> > > it seems the issue was in portaudio, which was hit by the locking
> > > behavior change.
> >
> > Good to hear that it's been addressed in portaudio side.
> >
> > But I still wonder in which code path the deadlock was triggered.
> > Can anyone give the stack traces of deadlocked (multi-)threads?
> 
> Actually, it wasn't so much the locking itself, but thread cancellation during 
> one call (snd_pcm_mmap_commit()) leaving the lock held and not released, 
> which then balked when a cleanup call to snd_pcm_drop() attempted to aquire 
> the lock.  This occurred as a result of an 'Abort' action in Portaudio.  It 
> can be avoided by disabling cancelablity at all times except when waiting on 
> poll(), though I have yet to be completely satisfied  there are no snags in 
> this approach, as cancelability is new to me!

OK, that relieves me.  Let me know if you still find anything odd
about the locking in alsa-lib, though.


thanks,

Takashi