Subject: Re: [linux-audio-dev] lock-free fifos
From: Tim Goetze (tim_AT_quitte.de)
Date: Sun May 12 2002 - 13:24:57 EEST
Ingo Oeser wrote:
>Hi Tim,
>
>On Sat, May 11, 2002 at 03:51:09PM +0200, Tim Goetze wrote:
>> i'm evaluating the following construct to implement a lock-free fifo
>> that allows more than one thread on the writer side:
>>
>> here, the i386 'xadd' instruction atomically adds 'i' to the counter
>> variable and returns the counter value before the add (obviously this
>> restricts the fifo size to powers of two so counter overflow can
>> safely be ignored).
>>
>> do you happen to know about the availability of an analogon to this
>> code on other processors than i386?
(i found out that xadd was introduced later than i386 in the meantime
btw.)
>Look into the implementation of atomic_add() of your favorite
>arch, because you just re-invented it badly ;-)
i'm well aware of <asm/atomic.h> on intel, it declares:
static __inline__ void atomic_add(int i, atomic_t *v)
^^^^
atomic_add does not return the counter value, so it's unusable for
what i'm talking about.
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.
>The problem is, that on some archs atomic operations are
>implemented using privileged instructions, so they cannot be used
can you specify which architectures use privileged instructions for
this purpose?
>in user space. But Linux 2.5 will have fast user space mutexes
>(the implementor calls these "futexes"), so you are basically
>wasting your time here ;-)
even if you make mutices faster, trying to acquire one while it's
being held by another thread must block (it would not be a mutex if
it did not for all i know). that's exactly what i'm trying to avoid.
thanks,
tim
This archive was generated by hypermail 2b28 : Sun May 12 2002 - 13:26:06 EEST