Re: [boost] [Boost.Lockfree] Interest in a ringbuffer class

Subject: Re: [boost] [Boost.Lockfree] Interest in a ringbuffer class
From: Raphaël Londeix (raphael.londeix_at_[hidden])
Date: 2017-01-26 08:51:23

>
> > The variable `buf' is stored inside the ring buffer, so that the commit
> > operation only change the position of the write cursor. One possible
> > way to do that is to define buffer as
>
> Personally speaking, if you're not using fixed size (and usually cache
> line aligned) items in thread shared memory storage, you've probably got
> the wrong design.
>

Nothing prevents us using something like this:

    struct buffer {
        size_type size;
        size_type capacity;
        size_type data[];
    };

Making it possible to align the buffer object.

I'm not sure what you are trying to say, my initial intent was to know
whether
or not some people might be interested in such a container.  Alignment,
cache
friendliness, false sharing, etc. are all implementation detail. Having one
thread
that produce some content and another consuming it is really a common
pattern.
The only different thing I'm trying to address here is that for some
problems, you
don't have fixed size objects.

> For example, if I were accumulating UDP packets using many threads, I'd
> keep a ring buffer per thread and timestamp their arrival using RDTSC so
> they could be reassembled into received order later if needed. That
> avoids multiple threads modifying the same memory which can become
> hideously slow.
>

I never said that *multiple* threads should modify the same memory. I've
only
ever talked about the single producer/single consumer case.

Also in your specific example, depending on the underlying protocol, you
won't
necessarily know the size of your packets, or the upper bound might still be
not practical to avoid a significant waste of space.

PS: your mails are always in the spam, even though I mark them at not spam
each time.

-- 
Raphaël Londeix
http://hotgloupi.fr