From: Abramo Bagnara <abramo.bagnara@libero.it>
To: Jeremy Hall <jhall@maoz.com>
Cc: Jaroslav Kysela <perex@suse.cz>,
"paul@linuxaudiosystems.com" <paul@linuxaudiosystems.com>,
"alsa-devel@lists.sourceforge.net"
<alsa-devel@lists.sourceforge.net>
Subject: Re: rme9652: possible deadlock
Date: Mon, 28 Apr 2003 10:58:44 +0200 [thread overview]
Message-ID: <3EACED44.2020102@libero.it> (raw)
In-Reply-To: <200304280823.h3S8NCUh029997@sith.maoz.com>
Jeremy Hall ha scritto:
> Will this fix allow both CPUs to run snd_pcm_period_elapsed() and friends
> concurrently and then if XRUN is encountered grab the group lock, or will
> one stream run at a time, in effect only allowing one card to process at a
> time?
As I've pointed to Jaroslav, current CVS code does not permit to both
CPUs to run the interrupt handler of two linked streams concurrently.
This is due to unconditional substitution of stream specific lock with a
linked group lock.
This is of course deadlock safe, but I think it's not the right solution.
I draw my current proposal (my previous proposal to Jaroslav concerning
that was flawed):
let's call stream specific locks S and the linked group lock G.
Whomever need to take stream specific lock take S.
When this need to be promoted to G, my proposal is to use code like this:
if (!spin_trylock(G)) {
spin_unlock(S);
spin_lock(G);
spin_lock(S);
}
This should solve all deadlock issues while retaining minimal lock
granularity.
--
Abramo Bagnara mailto:abramo.bagnara@libero.it
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
next prev parent reply other threads:[~2003-04-28 8:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-14 18:47 rme9652: possible deadlock Jeremy Hall
2003-04-22 14:16 ` Jaroslav Kysela
2003-04-22 19:22 ` Jeremy Hall
2003-04-22 19:42 ` Jaroslav Kysela
2003-04-22 22:04 ` Jeremy Hall
2003-04-23 9:51 ` Jaroslav Kysela
2003-04-23 15:06 ` Jeremy Hall
2003-04-23 19:19 ` Jaroslav Kysela
2003-04-24 10:03 ` Abramo Bagnara
2003-04-28 8:23 ` Jeremy Hall
2003-04-28 8:58 ` Abramo Bagnara [this message]
2003-04-28 9:58 ` Jaroslav Kysela
2003-04-28 10:11 ` Abramo Bagnara
2003-04-28 12:27 ` Jaroslav Kysela
2003-04-28 12:47 ` Abramo Bagnara
2003-04-28 18:16 ` Jaroslav Kysela
2003-04-28 19:15 ` Abramo Bagnara
2003-04-28 8:25 ` Jeremy Hall
2003-04-28 8:44 ` Jeremy Hall
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=3EACED44.2020102@libero.it \
--to=abramo.bagnara@libero.it \
--cc=alsa-devel@lists.sourceforge.net \
--cc=jhall@maoz.com \
--cc=paul@linuxaudiosystems.com \
--cc=perex@suse.cz \
/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.