[alsa-devel] Races in alsa-lib with threads

Krakora Robert-B42341 B42341 at freescale.com
Wed Nov 14 21:06:22 CET 2012

From: alsa-devel-bounces at alsa-project.org [alsa-devel-bounces at alsa-project.org] on behalf of Rémi Denis-Courmont [remi at remlab.net]
Sent: Wednesday, November 14, 2012 3:03 PM
To: alsa-devel at alsa-project.org
Cc: Trent Piepho
Subject: Re: [alsa-devel] Races in alsa-lib with threads


Le mercredi 14 novembre 2012 21:49:36, Trent Piepho a écrit :
> > You claim that the Gstreamer ALSA sink plugin accesses alsa-lib from two
> > threads simultaneously. Could you elaborate on how this can happen, maybe
> > it is easy to fix?
> gstreamer has no lock around the call to snd_pcm_delay().  So it can
> race with snd_pcm_wait() or snd_pcm_writei(), which are called in
> another thread.  There is a lock around the block of code calling
> wait()/writei(), but this lock isn't used for calling delay().

Use non-blocking I/O and poll(). Then the snd_pcm_write() calls will not sleep
and can be interlocked with snd_pcm_delay() calls.

> It seems that they didn't know there would be a problem.

Eh? It is rather the exception for a library to be thread-safe when using the
same object in multiple threads.

It looks more like "they" did not pay attention to what they were doing.

Rémi Denis-Courmont
Alsa-devel mailing list
Alsa-devel at alsa-project.org

HI Rémi,

We are using non-blocking mode with snd_pcm_wait() and snd_pcm_writei().  We have a workable solution.  Thanks for the advice.

Best Regards.


More information about the Alsa-devel mailing list