Subject: Re: [boost] [Lockfree] ringbuffer
From: Rich E (reakinator_at_[hidden])
Date: 2013-02-08 23:13:41
Now that I've been using lockfree::spsc_queue a bit, I was wondering why
there is no method to retrieve write_available() on the producer end. It
seems like it would be more efficient to be able to retrieve this before
writing in some cases, like say when you want to overwrite old values from
the producer thread in order to keep the data fresh. Instead, I'm having
to do two push()'s.
p.s. Please let me know if I should resort to the boost users forum instead
of this one for questions like these.
On Sun, Jul 8, 2012 at 10:54 PM, Rich E <reakinator_at_[hidden]> wrote:
> Thanks for the clarification, that makes perfect sense. Good to know
> about being able to configure memory usage. I look forward to trying these
> out in the coming days..
> On Sun, Jul 8, 2012 at 3:27 AM, Tim Blechmann <tim_at_[hidden]> wrote:
>> >> First off, all Boost.Lockfree tests in trunk are passing for me on
>> >> 4.0 on OS X, hurrah! Thank you Tim for working on this for so long...
>> >> I'm running through the examples now, only with the outdated
>> >> as a guide (more than a couple years old). I cannot find the
>> >> container - was it renamed or removed altogether during the review
>> >> I notice spsc_queue acts awefully like a ringbuffer, and it's
>> >> implementation contains many
>> > ... ringbuffer-like classes - is this the decided class for creating a
>> > lockfree buffer that reuses memory?
>> the ringbuffer was renamed to spsc_queue: internal data structure is a
>> ringbuffer, but it models a single-producer single-consumer wait-free
>> queue. so the name reflects the properties rather than the
>> implementation. iirc the same data structure is called `bounded queue'
>> in shavit/herlihy, fifo in the linux kernel and ringbuffer in many
>> audio-related projects.
>> btw, all data structures in boost.lockfree can be configured to reuse
>> memory in order to be usable in systems where you want to avoid memory
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk