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

[Takashi Iwai]

At Tue, 13 Nov 2012 14:04:22 +0000,
Krakora Robert-B42341 wrote:
> 
> >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
> >stuff.
> >
> >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).
> >
> >Takashi
> 
> Hi Takashi,
> 
> OK, but it sure seems as though the better fix would be in ALSA Lib
> (but then ALSA Lib assumes a great deal of risk unless it is
> re-architected for thread safety).

Yeah, introducing a thread-safe requires some fundamental redesign.
Otherwise we need pthread lock which is always risky to break
something.

>  However, you have an already established paradigm so I will see
>  what I can do in the GStreamer ALSA Sink plugin.

Thanks!


Takashi