Subject: Re: [linux-audio-dev] MidiShare Linux
From: Stephane Letz (letz_AT_grame.fr)
Date: Thu Jul 20 2000 - 11:52:47 EEST
>That means if you want to be sure that it works everywhere
>you have to ship the SMP version.
I think using the "lock" instruction is costly when used in UP. You should
better provide
two versions, actually by using the __SMP__ flag.
We will publish some benchmark to show that.
>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 ?
Just a temporary solution.
>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)
>
Will must implement the fifo directly using inlined assembly language ,
using the "magic" instructions
"cmpxchg8b" and so on.
>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.
So it means that all readers read the same element?
Actually i don't really understand the way your fifo (with ringbuffer) works.
How can you garantee that the write operations works correctly in a
multi-thread context?
Can you explain the design ?
Stephane Letz
Grame: Centre National de creation musicale
9, Rue du Garet
69001 Lyon
Tel: 04-72-07-37-00
Fax: 04-72-07-37-01
Web: www.grame.fr
This archive was generated by hypermail 2b28 : Thu Jul 20 2000 - 12:32:40 EEST