Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jaroslav Kysela <perex@perex.cz>
To: Takashi Iwai <tiwai@suse.de>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Trent Piepho <tpiepho@gmail.com>,
	Krakora Robert-B42341 <B42341@freescale.com>
Subject: Re: Races in alsa-lib with threads
Date: Tue, 13 Nov 2012 15:08:29 +0100	[thread overview]
Message-ID: <50A2545D.4090106@perex.cz> (raw)
In-Reply-To: <s5h4nktipd5.wl%tiwai@suse.de>

Date 13.11.2012 14:50, Takashi Iwai wrote:
> 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).

I tried to put notes on the ALSA Wiki, please, extend / fix / review.

http://www.alsa-project.org/main/index.php/SMP_Design

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

  parent reply	other threads:[~2012-11-13 14:08 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-10  2:03 Races in alsa-lib with threads Trent Piepho
2012-11-10 13:53 ` Takashi Iwai
2012-11-11 16:35   ` Jaroslav Kysela
2012-11-12 19:40     ` Rob Krakora
2012-11-13  6:32       ` Takashi Iwai
2012-11-13  7:14         ` Trent Piepho
2012-11-13  7:30           ` Takashi Iwai
     [not found]             ` <5175C6FEA820754B902FF6873E9285B00C985240@039-SN2MPN1-021.039d.mgd.msft.net>
2012-11-13 13:47               ` Krakora Robert-B42341
2012-11-13 13:50               ` Takashi Iwai
2012-11-13 14:04                 ` Krakora Robert-B42341
2012-11-13 14:18                   ` Takashi Iwai
2012-11-13 14:08                 ` Jaroslav Kysela [this message]
2012-11-13 14:15                   ` Krakora Robert-B42341
2012-11-13 14:19                   ` Takashi Iwai
2012-11-13 14:26                 ` Krakora Robert-B42341
2012-11-13 19:41                 ` Trent Piepho
2012-11-13 20:23                   ` Clemens Ladisch
2012-11-13 20:36                     ` Trent Piepho
2012-11-13 20:29                   ` Takashi Iwai
2012-11-13 20:55                     ` Krakora Robert-B42341
2012-11-13 21:11                       ` Krakora Robert-B42341
2012-11-13 20:52                   ` Krakora Robert-B42341
2012-11-14  8:02                   ` David Henningsson
2012-11-14 12:55                     ` Krakora Robert-B42341
2012-11-14 19:49                     ` Trent Piepho
2012-11-14 20:03                       ` Rémi Denis-Courmont
2012-11-14 20:06                         ` Krakora Robert-B42341
2012-11-14 20:54                         ` Trent Piepho
2012-11-14 21:19                           ` Rémi Denis-Courmont
2012-11-15  1:52                             ` Krakora Robert-B42341
2012-11-15  7:39                       ` Takashi Iwai
2012-11-15 13:05                         ` Krakora Robert-B42341

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50A2545D.4090106@perex.cz \
    --to=perex@perex.cz \
    --cc=B42341@freescale.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=tiwai@suse.de \
    --cc=tpiepho@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox