[alsa-devel] Races in alsa-lib with threads
B42341 at freescale.com
Tue Nov 13 15:26:33 CET 2012
From: Takashi Iwai [tiwai at suse.de]
Sent: Tuesday, November 13, 2012 8:50 AM
To: Krakora Robert-B42341
Cc: Trent Piepho; alsa-devel at alsa-project.org
Subject: Re: [alsa-devel] Races in alsa-lib with threads
At Tue, 13 Nov 2012 13:39:24 +0000,
Krakora Robert-B42341 wrote:
> [1 <text/plain; us-ascii (quoted-printable)>]
> > From: Takashi Iwai [tiwai at suse.de]
> > Sent: Tuesday, November 13, 2012 2:30 AM
> > To: Trent Piepho
> > Cc: Krakora Robert-B42341; alsa-devel at alsa-project.org
> > Subject: Re: [alsa-devel] Races in alsa-lib with threads
> > At Tue, 13 Nov 2012 02:14:08 -0500,
> > Trent Piepho wrote:
> > >
> > > On Tue, Nov 13, 2012 at 1:32 AM, Takashi Iwai <tiwai at suse.de> wrote:
> > > > At Mon, 12 Nov 2012 19:40:42 +0000 (UTC),
> > > > Rob Krakora wrote:
> > > >> Would you be able to point me the the ALSA documentation that indicates the
> > > >> stipulations on handle usage using multiple threads? I cannot find it.
> > > >
> > > > Think other way round:
> > > > The fact that it isn't documented means it's not safe to use in that
> > > > way :)
> > >
> > >
> > > The introduction on the alsa-project home page says, "SMP and
> > > thread-safe design. " Some people might misunderstand what
> > > thread-safe means. Maybe some clarification could be added.
> > > "Different streams are SMP and thread-safe (calls for the same stream
> > > must be serialized)."
> > Yeah this should be corrected. SMP things are just about the kernel
> > side at that time.
> > It's a Wiki, feel free to correct / improve the text.
> > Takashi
> Hi Takashi,
> The way that the GStreamer ALSA Sink Plugin is using ALSA Lib assumes that it is thread safe. The fix crafted by one of Trent's colleagues (attached) seems to be the way to go. However, I don't know how it would impact other functionality within ALSA Lib.
No, sorry, we don't want to introduce pthread_lock in alsa-lib PCM
We already have a few places, yes, but they are exceptional (mostly
for funky rarely used plugins that we can drop or mixer codes that
are no hot path).
A colleague found this from two years ago: http://mailman.alsa-project.org/pipermail/alsa-devel/2010-June/028347.html.
IMHO, it seems trivial and harmless to serialize appl.ptr updates with mutexes unless there is a potential for deadlock or other possible race conditions in the affected ALSA Lib functions. I know it breaks the paradigm, but you can see how snd_pcm_delay() function can lead a developer to believe that it can be called on a different thread time from snd_pcm_writei().
More information about the Alsa-devel