At Tue, 13 Nov 2012 14:04:22 +0000, Krakora Robert-B42341 wrote:
From: Takashi Iwai [tiwai@suse.de] Sent: Tuesday, November 13, 2012 8:50 AM To: Krakora Robert-B42341 Cc: Trent Piepho; alsa-devel@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@suse.de] Sent: Tuesday, November 13, 2012 2:30 AM To: Trent Piepho Cc: Krakora Robert-B42341; alsa-devel@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@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