Re: [linux-audio-dev] lock-free fifos

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] lock-free fifos
From: Tim Goetze (tim_AT_quitte.de)
Date: Mon May 13 2002 - 14:39:07 EEST


Ingo Oeser wrote:

>Hi Tim,
>
>On Sun, May 12, 2002 at 12:24:57PM +0200, Tim Goetze wrote:
>> nevertheless, i went looking at the other archs and very much to my
>> surprise found corresponding code for ppc and sparc for example. to
>> my surprise because i assume it to be unused, otherwise there'd be an
>> implementation for every arch. i'm still thinking whether relying on
>> this unused code is a good idea.
>
>It looks safe in some cases. Most of them just implemented it,
>because it is possible and not included in the actual kernel code
>if never called (because it's inline ;-)). Some of these
>generalized the atomic inc/dec and test with them.

basically i do expect them to work. on sparc fe, atomic_inc_return
is actually the same code as atomic_inc, ditto for the rest of the
suite (on sparc). i'd have to dig a little deeper into ppc assembly
to figure out how the multi-instruction atomic_* work there without
being preempted.

>> can you specify which architectures use privileged instructions for
>> this purpose?
>
>Architectures, which use cli/sti to implement it. This is almost
>always an privileged instruction, so no user can stall interrupt
>processing of the kernel on sane architectures. arm and cris come
>to mind.

yup, that's a problem. but since they use cli/sti even for simple
atomic_inc, i've already excluded them from the list of possible
ports ... ignorance on my part, but ignorance on the part of the
respective cpu designers as well imo.

>Use trylock and spin for a while to simulate "spinlocks" and
>avoid the schedule. But atomic operations are always better,

it's pointless to spin on a pthread_mutex_trylock in a SCHED_FIFO
thread on a single-processor system if there are no SCHED_FIFO
threads running at higher priority, which should be the case for
an audio thread. atomic operations aren't just the better, they
are the only choice in this case imo (unless you install per-thread
fifos).

thanks,

tim


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon May 13 2002 - 14:34:49 EEST