[alsa-devel] locking looks odd

[Takashi Iwai]

On Sat, 20 Aug 2016 14:12:05 +0200,
Samuel Thibault wrote:
> 
> Jaroslav Kysela, on Wed 17 Aug 2016 19:46:42 +0200, wrote:
> > Dne 16.8.2016 v 23:03 Samuel Thibault napsal(a):
> > > - snd_pcm_new seems to initialize pcm->thread_safe to 0 by default, this
> > >   does not seem safe. The attached patch initializes it to 1, which
> > >   fixes the bug in our tests.
> > > 
> > > - snd_pcm_hw_open_fd forces it to 1, thus ignoring what snd_pcm_new set.
> > 
> > The thread_safe has this meaning:
> > 
> > 0  - the pcm plugin is not thread safe
> > 1  - the pcm plugin is thread safe (actually only the hw plugin)
> > -1 - disable thread safety
> 
> So now with rethinking all of this, I'm starting to understand: from
> reading the variable name, I would have thought "thread_safe=1" means
> "I want thread safety thanks to a mutex", while apparently it means
> "the plugin is already thread-safe, there is no need for a mutex"...
> Really, all of this should be documented clearly along the source code,
> otherwise people will get it wrong.

Sorry for unclearness.  An improvement patch is always welcome :)


> 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: the
> mentioned Debian report is far from alone, the upgrade to the newer
> libasound has severely broken quite a few applications, I'm at the point
> of advising the Debian maintainer to just revert to the previous version
> for Stretch, otherwize we'll be shipping just very-buggy software.

Basically the alsa-lib is not thread safe.  The new thread-safe
implementation was introduced just because there are way too many 
buggy applications that work casually for now.  It's not meant as the
rock-solid thread-safety alone.

If the application deadlocks with the alsa-lib with the thread-safe
option enabled, it's most likely that the application does already
accessing alsa-lib in a wrong, racy way.

In anyway, it'd be helpful to get stack trace of threads at the
hanging moment.  It'll clarify how the deadlock is triggered.  The
plugin may become a complex chain, and there might be something
missing in the big picture.


thanks,

Takashi