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

[Krakora Robert-B42341]

>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).  However, you have an already established paradigm so I will see what I can do in the GStreamer ALSA Sink plugin.

Best Regards,

Rob Krakora