🚀 go-pugleaf

Alan Bellingham wrote:

>If the buffer writing code writes more than a single int (and I'm making
>the unwarranted assumption that writing an int is atomic), it may have
>problems. Assume it writes two ints:
>
>  thread 1 - reads buffer, sees no change
>  thread 2 - write first int
>  thread 1 - reads buffer, sees change, reads first int, reads second
>   (as yet unchanged)
>  thread 2 - write second int
>
>Here the reading thread read something which isn't what the writer
>wrote.

There should be a way around that.
In my experience, a circular buffer has 2 pointers, In and Out.

The Writer reads In and Out.  If In == Out-1 (don't forget to account
for wrap), buffer overflow.
Otherwise writes to buffer[In], writes In=(In+1)mod size

The Reader reads In and Out. If ==, go away, no data.
Otherwise, reads Buffer[Out], writes Out=(Out+1)mod size.

Points:
In isn't updated until after the data is in the buffer, so Reader
doesn't attempt to read garbage data.

Out isn't written until the data has been removed, so Writer doesn't
overwrite.

>The writing frequency is fairly irrelevant - all that matters is whether
>_when_ writing occurs, it is possible that reading may occur before it's
>finished.

Which it won't do if it doesn't know that writting is happening.
It will think nothing has come in until the writer has finished.

And if the buffer is full, the writer won't know that the reader is
attempting to empty it, so will block (or handle the overflow somehow
other than continuing to write).
With CRC verified communications, the overflow might result in dropped
data, to be caught by the CRC. In other communications, the Writter
might respond to the comm with a Nak or a Wait (just a bit before the
buffer fills, 80-90%), to stem the tide.

OTOH, if there are multiple Readers, then the Readers need to be
protected from each other.
Likewise, multiple writers from each other.
But, I would think multi-reader/writers would be confusing, as to what
data belongs to whom?