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