Subject: [linux-audio-dev] lock-free structures ... Re: MidiShare Linux
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Fri Jul 21 2000 - 18:20:58 EEST
On Fri, 21 Jul 2000, David Olofson wrote:
> On Thu, 20 Jul 2000, Stephane Letz wrote:
> > >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.
>
> Hmm... This is definitely a reason to make sure that plugins don't
> have to deal with these kinds of lock-free interfaces directly.
>
> (As to MuCoS, the idea is to base the plugin API on simple, open
> structs and inline code/macros. Plugins won't run in separate threads
> anyway, and in the rare cases where you really want to do that, the
> hosts will deal with these matters as a part of the IPC.)
>
>
> //David
I think that applications running as plugins, will need to use these data
structures heavily so we have to solve the SMP/UP issues in advance.
Fortunately on the x86 the code remains the same ( atomic_read and atomic_set
do not use the lock instruction).
As for providing ringbuffer code in a library, I am a bit against it,
because the compiler can't inline the code, making it much slower.
(I am thinking about the case where you access these datastructures
heavily, thousand times per second (as in disksampler) )
With inlining we get down (almost) to the strictly necessary assembly
instructions, thus the speed is unbeatable.
So in the x86 case we simply could provide source level API ( eg ringbuffer.h)
which gets then inlined by the compiler.
On UP/SMP SPARCs the situation would be more complicated because there IS
a difference in the macros.
If you want truly optimized code, I see no big way around shipping UP and SMP
versions of the plugin, though the SMP version will run on UP too, but will be
slower than native UP.
Alternatives ?
(keep speed in mind, without speedy lock-free FIFOs, we will add CPU overhead
when the access frequency increases)
But perhaps it would be useful to ask the linux-kernel guys to run some
benchmarks on SMP SPARCs to get an idea of the speed differences.
Fortunately atomic_read /set macros on PPC remain the same on both SMP/UP,
so at least on the 95% (or more) boxes in circulation, we will not face this
issue.
Benno.
This archive was generated by hypermail 2b28 : Fri Jul 21 2000 - 18:21:17 EEST