Re: [LAD] Atomic Operations

From: Tim Blechmann <tim@email-addr-hidden>
Date: Tue Dec 15 2009 - 20:47:50 EET

>>> http://github.com/radarsat1/dimple/blob/master/src/CircBuffer.h
>>
>> you should add memory barriers, when reading or writing to the reader or
>
> Actually, his implementation is similar to ringbuffer.c in
> libjack... and assumes that reading and writing can happen
> atomically (as was pointed out by someone else) -- which can
> be managed with single reader / single writer
> requirement.[a]
>
> Unless I've misunderstood the code, ringbuffer.c is /not/
> using special atomic operations.

the jack ringbuffer code is not multiprocessor safe then ... it is prbly
not an issue for jack1, but maybe for jack2, if it is used there ...

>> writer indices ... my implementation (without size limitation to a power
>> of two) can be found at [1]
>>
>> [1]
>> http://tim.klingt.org/git?p=boost_lockfree.git;a=blob;f=boost/lockfree/ringbuffer.hpp;h=139f79869f610c61b0d117d2836a3c8c4949db02;hb=03d4e397a74f2b85c87f6b54b4755428956ff63a
>
> This looks nice, too. Have you considered trying to give it
> an interface like the existing boost::circular_buffer<T,Alloc>?
> The distinguishing feature of your implementation is that is
> lock-free... but it's otherwise the same concept (and
> already in Boost).

i actually tried to match the interface to boost::lockfree::fifo, which
provides a multi-producer/multi-consumer queue.

> Also, does yours have a single reader / single writer
> requirement?

yes

> I tried to clone the git repos, but hit ^C when it was
> 20% and 40MB (!!). :-)

it includes the full source tree of boost (160mb on my machine)

cheers, tim

-- 
tim@email-addr-hidden
http://tim.klingt.org
Happiness is a byproduct of function, purpose, and conflict; those who
seek happiness for itself seek victory without war.
  William S. Burroughs

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Received on Wed Dec 16 00:15:01 2009

This archive was generated by hypermail 2.1.8 : Wed Dec 16 2009 - 00:15:01 EET