Subject: Re: [linux-audio-dev] MidiShare Linux
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Wed Jul 19 2000 - 21:25:43 EEST
On Wed, 19 Jul 2000, Paul Barton-Davis wrote:
> >I thought 32bit accesses are atomic on x86 boxes (both up and SMP) ?
>
> Depends on how you use them. For bounded FIFO's, its probably OK to
> leave out the "lock" instruction on the x86. But it does change the
> semantics in a subtle way. The instruction is atomic, yes, but without
> the "lock", you can't ensure correct execution in some cases where the
> processor reorders instructions.
but looking at asm/atomic.h the read and set macros are a simple assignement:
#define atomic_read(v) ((v)->counter)
#define atomic_set(v,i) (((v)->counter) = (i))
that means the ringbuffer.h should just work since
we first read the write and readpointers , increase the values
in a private variable and then write them back.
The atomic add and sub macros instead use the lock instruction
in case of SMP.
I will port the ringbuffer.h code to use these macros
(atomic_t types, atomic_read(), atomic_set() ,
void atomic_add() and atomic_sub() )
so that any fear will go away.
A remaining problem I see is that the macros check
#ifdef __SMP__
In that way compiling the app on an UP, will not produce
SMP-safe lock-free code.
That means if you want to be sure that it works everywhere
you have to ship the SMP version.
(Correct me if I am wrong)
>
> No. Based on Yann's presentation at the LSM (which i missed most of
> because I was struggling with a photocopier :() MidiShare uses lock
> free *lists*, not lock free managed arrays. So they can keep
> arbitrarily long lists of events, and not be fixed to some
> predetermined size. Before you jump on all the obvious problems with
> this, go and take a look at MidiShare first. The folks from GRAME are
> not beginners with this stuff you know.
If you need linked lists where elements can be inserted/removed at arbitrary
points, the the lock-free ringbuffer is obviously not a suitable structure.
But both will face the problem of having all the memory mlock()ed in
physical RAM, thus there is no concept of "arbitrarily long lists of events".
The list has an upper bound which is determined by the preallocated
memory area.
at lest, few comments about Stephanes mail:
Stephane Letz wrote:
> Lock-free fifo is currently implemented using two lock-free lifo, but thisis
> not completly general. It only works correctly when they are several writers
> and only one reader. A general implementation has still to be done.
Why implement a lock-free fifo on top of two lock-free lifos ?
It's just not optimal from a CPU cycles POV (but I could miss something in your
design so correct me if I am wrong)
About the "only one reader" issue: yes the lock-free fifo I'm using , assumes
this, but we colud add the following:
let's say we always know the number of readers:
each reader reads form the FIFO but does not increase the read pointer.
reach reader (atomically) increases a member (count) of the dataset with was
just read, and as soon as it reaches NUM_READERS we will increase the read
pointer and reset to zero.
Not sure if adding / removing clients at runtime would cause races.
thoughts ?
Benno.
This archive was generated by hypermail 2b28 : Wed Jul 19 2000 - 21:18:33 EEST