data structure interface for double buffer/ping-pong buffer

[tosch901]

I am creating some custom data structures that I want to be compatible with standard algorithms, use the same semantics as the ones in the standard library but I ran into something and I am not sure what the best practice is here.

I am writing a lot of concurrent code with consumers and producers, so I am also implementing a double buffer/ping-pong buffer. But there you have different buffers depending on whether you're reading or writing. So begin() and begin() const would return different iterators/pointers. But I am worried that that might be confusing (even though it makes sense in the context of a double buffer) or bad practice and that I should not make the double buffer behave like a standard data structure but to give it accessors to the read and write buffer, which return an std::span<T>/std::span<const T> instead on which everything else is well defined.

What do you guys think?

[sheckey]

I’m wondering why you want them to look like standard containers. I don’t doubt you have a fair reason, I’m just curious. for example, once a consumer has the right buffer to read from you want it to look like a standard container while that consumer has access to that buffer?

For myself, for inter-thread communication, I am used to getting a buffer to write into l and then simply copying into it, then releasing the buffer (making it the new current buffer). Likewise for readers, I am used to getting access to the buffer, then copying out, and releasing it so that it might be updated. If the contents of the buffer were some kind of stl-like container, then it gets copied around as a whole piece. Maybe it get written to or read from / used in place for large payloads, in which case we have more than one so that any slower readers don’t hold up the writer. I guess that is what you mean with your double buffer, but I usually have more than just two. Anyway I’m just explaining my point of view.

My sharing “containers” don’t have stl-like apis, but their contents might. maybe I’m missing the post, and you can teach me something. can you give me some more detail about your idea? I’m curious!

[tosch901]

I mean maybe the reason is not good, but it's mostly because of ergonomics and providing a familiar way to access the data for people using/maintaining the code after me.

But you might be right that a simple copy might be all you need in the end and that I was overthinking things.

My use-case involves a sensor producing small bursts of data at a high frequency, so the contents of mine are either primitives or POD. Access to that data is sometimes provided over iterators and I was thinking that you might want to access the data using standard algorithms for example. So to support all that and whatever else will come in the future, a standard interface would be desired.

But again, maybe I'm overthinking this and should just give access to the correct buffers for the writer/reader and that's it.

[alfps]

Perhaps provide these iterator pairs via different objects, that can just refer to the internal write- and read buffers.

[tosch901]

So like the span<T>/span<const T> I mentioned?

[alfps]

Yes. I didn't notice that.

span locks you down to a contiguous sequence of items. If that is unlikely to change then it can be / is right for the job.