Re: atomicity in linked streams

From: Takashi Iwai <tiwai@suse.de>
To: Eliot Blennerhassett <bigblen@icqmail.com>
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: atomicity in linked streams
Date: Wed, 23 Jul 2003 10:48:47 +0200	[thread overview]
Message-ID: <s5hoezlfx1s.wl@alsa2.suse.de> (raw)
In-Reply-To: <20030721191918.18068.h006.c012.wm@mail.icqmail.com.criticalpath.net>

At Mon, 21 Jul 2003 19:19:17 -0700 (PDT),
Eliot Blennerhassett wrote:
> 
> Takashi Iwai wrote:
> > Hi,
> > 
> > so far, some pcm operator callbacks are assumed to be atomic.
> > but looking at the code, this restriction seems coming only from the
> > rwlock of linked streams.
> > 
> > there are some hardwares which need (idally) the non-atomic operations
> > for prepare and trigger.  they usually require the ack as the command
> > completion.  and we implemented it in the busy loop or by ignoring the
> > ack.
> 
> Can you point me to an example...

korg1212 and vx drivers do in these ways.

> I would be very glad if operators were non-atomic (I could handle .pointer being
> atomic).  
> I have had to replace a semaphore with a spinlock around my card access code
> because there are a few paths that come from atomic context.

yes, this is the very reason i posted.

> Maybe it is a big picture design flaw...

it's rather a subtle thing in the total design, i'd like to say :)
in most parts you don't need to change.

> > i think the stream-link lock can be replaced with rw_semaphore, so
> > that prepare and trigger callbacks can be non-atomic.  the only
> > critical part is, as far as i see, that  snd_pcm_stop() may be called
> > from interrupt handler when  xrun/suspend happens.  this cannot handle
> > the semaphore, of course.
> > 
> > i have still no concrete idea how to solve this...  any suggestions?
> 
> Is it possible that semaphores can be used in atomic context if down_trylock()
> is used in a loop?  Really what is not allowed is for process to try to sleep
> when in atomic context.

no, this will surely cause a deadlock.

> Now I think about it it would cause a deadlock.  How about have the interrupt
> flag the need to stop after the competing process relinquished the semaphore?

that's what i thought of, too...

ciao,

Takashi

-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0