2 ms·
In general, this makes sense; certainly data you're putting into a ring buffer is data you're willing to lose. Doesn't it break the order invariant of the buff
by Bartweiss 10y ago
In general, this makes sense; certainly data you're putting into a ring buffer is data you're willing to lose.
Doesn't it break the order invariant of the buffer, though? I can't see a way to do this without the risk of getting reads of newer data prior to older data. That's probably fine in many cases, but something like non-timestamped-debugging strikes me as a case where I'd want to know that the data arrived in the order I'm seeing.
- falcolas 10y ago> Doesn't it break the order invariant of the buffer, though No, if you increment the read pointer prior to the write pointer, the read pointer will still point at the oldest valid value in the buffer. So, in pseudo code: if (w+1 >= r) { r = w + 2 } w++ b[w-1] = value For a debugging ring buffer (i.e. looking at it in a core file), you have the last value of the write pointer, so you can simply read from write pointer + 1 back around to the write pointer and have your messages in order. This makes the assumption that there is no readers of the debug buffer, so you're only having to deal with the one pointer.
- dllthomas 10y ago> certainly data you're putting into a ring buffer is data you're willing to lose. When that's the case, a ring buffer is a great choice. It's not required, though - the writer could block when it detects a full buffer.