All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.