Subject: Re: [linux-audio-dev] MidiShare Linux
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Thu Jul 20 2000 - 16:35:35 EEST
On Thu, 20 Jul 2000, Paul Barton-Davis wrote:
> >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 ?
>
> as the "designer" of the thread safe version, i'll push my way in here :)
Perhaps Stephane meant thread safe in sense of multiple writers and one
reader, and this is where this ringbuffer approach fails.
But as said in my other mail, it's simplicity and efficiency is almost
unbeatable by other approaches, and in many problems you can
transform the "multiple writers with one reader" problem into
one writer per fifo plus a reader which reads all the fifos in sequence.
This is what I do in both hdrbench and disksampler, and it works like a charm.
Still waiting that someone explains me the multiple writer FIFO algorithm. :-)
>
> The net result is that these computations are always thread safe if
> there is just one reader and one writer. The only detail is that its
> possible to underestimate the data or space available, and thats
> nearly always completely OK.
I was wondering in which cases this would NOT be ok, I can't currently
think of any.
>
> Note that I have a more efficient implementation of a lock-free FIFO
> for use where the characteristics of a ringbuffer are not desired
> (i.e. you really are always just pushing and popping elements from the
> FIFO). The ringbuffer implementation allows it to be used to store
> streaming data efficiently, but is not so quick for simple push/pop
> operations.
who says that ? :-)
writing only one element at time in the ringbuffer using:
ptr=buffer->get_write_ptr();
*ptr=data;
buffer->increment_write_ptr(1);
produces the same efficient code as a "native" lock-free fifo.
And gcc translates the increment_write_ptr(1) instruction
in an INC + AND , (instead of ADD + AND if the increment
value is different than 1). Who said that gcc produces inefficient code ?
With the above approach I have the best of both worlds:
full ringbuffer behaviour , so if I am lazy, I can use the a bit slower read()
write() functions, and if I need maximum speed (which assumes that you
always write a power of two elements, and always the same size) I can access the
buffer using the above method.
Benno.
This archive was generated by hypermail 2b28 : Thu Jul 20 2000 - 16:28:40 EEST