[jlokier]

> In point of fact, only low-level drivers need concern themselves with ring buffers.

As a side point, ring buffers are also useful in some high-level, high-performance code that is multi-threaded or using multi-processors.

io_uring is an example of this used to speed up Linux kernel-userspace communication (although it's not a great example for illustrating the general principle because it's so specialised).

DSPs use ring buffers extensively. Mainly for signal data, but sometimes for communicating tasks and messages between coprocessors.

[ChrisMarshallNY]

Cool! I did not know that, but it makes sense, as ring buffers were developed specifically to handoff between thread/clock contexts.

I haven't played that low in the dirt for many years. I suspect it's a very different world from the one I once knew.

I'm grateful for the abstraction. Low-level comms stuff is pretty damn hairy.

[tonyarkles]

Heck, I’m using ring buffers in some high performance image processing stuff right now. There’s non-constant-time processing in the pipeline, and dropping frames is acceptable if we hit some kind of pathological case where the image processing stuff can’t keep up. Pseudo-real-time is more important than processing every frame, but processing as many frames as possible is still desirable. By adjusting the size of the ring buffer relative to the input rate, we can put a bound on the maximum age of a buffered frame (camera runs at a fixed fast rate) while guaranteeing we’ll never exceed N*frame size memory usage.

[ChrisMarshallNY]

That also makes sense. We used to call that behavior "isochronous." Do they still call it that?