Or the same demonstration without a very confusing overloaded identifier
(sorry!):
https://go.dev/play/p/ChOkAyV8imA?v=gotip
On Friday, March 11, 2022 at 8:52:04 AM UTC-7 Gregg Townsend wrote:
> Well, the suggested code passes the race detector, but shouldn't it also
> be *correct*?
> Two concu
Btw, for those interesting in some neat highly optimized queue patterns check
out https://lmax-exchange.github.io/disruptor/
> On Mar 11, 2022, at 5:58 PM, Robert Engels wrote:
>
>
> “Usually” SPSC means it is optimized for that case but it doesn’t fail in
> case of multiple writers. It it u
“Usually” SPSC means it is optimized for that case but it doesn’t fail in case
of multiple writers. It it usually easier to prevent multiple readers as the
reader can be controlled during init and hidden.
> On Mar 11, 2022, at 4:41 PM, 'Axel Wagner' via golang-nuts
> wrote:
>
>
>
>
>> On
On Fri, Mar 11, 2022 at 4:51 PM Gregg Townsend wrote:
> Well, the suggested code passes the race detector, but shouldn't it also
> be *correct*?
> Two concurrent calls of Put can load identical head and tail values and
> then store in the same slot.
>
The premise is that there is a single consum
On Fri, Mar 11, 2022 at 9:26 AM Brian Candler wrote:
>
> On Friday, 11 March 2022 at 15:52:04 UTC Gregg Townsend wrote:
>>
>> Two concurrent calls of Put can load identical head and tail values and then
>> store in the same slot.
>
>
> Correct, but that's not a valid way to use this code. See
>
On Friday, 11 March 2022 at 15:52:04 UTC Gregg Townsend wrote:
> Two concurrent calls of Put can load identical head and tail values and
> then store in the same slot.
>
Correct, but that's not a valid way to use this code. See
https://github.com/QuantumLeaps/lock-free-ring-buffer#lock-free-res
On Thu, Mar 10, 2022 at 10:31 PM Cameron Elliott wrote:
>
> Ian, thank you very much for the suggestion to use atomics.
> Unfortunately, for a standard SPSC ring buffer, I don't think it does the
> trick.
>
>
> I am attaching a simple ring buffer program at the end.
>
> If you run 'go run -race m
Well, the suggested code passes the race detector, but shouldn't it also be
*correct*?
Two concurrent calls of Put can load identical head and tail values and
then store in the same slot.
See
https://go.dev/play/p/gagBCCj2n2g?v=gotip
for a demonstration.
On Friday, March 11, 2022 at 12:24:42 AM
I found a lock-free ringbuffer implementation written in C, which seems to
do what you want:
https://github.com/QuantumLeaps/lock-free-ring-buffer/blob/main/src/
This is a relatively direct translation to Go, using generics from go 1.18
(to be released very soon):
https://go.dev/play/p/nNEt66r71Yf?
Uhm, I just actually looked at the code.
You still use `r.start %= N`, which is a non-atomic access to r.start.
AIUI, SPSC stands for "single producer, single consumer", i.e. you know
that Get and Put will only be called from a single goroutine, respectively?
In that case, you wouldn't even need at
You probably want to make the element type of the slice an atomic.Value,
instead of an interface{}. You shouldn't need a mutex then.
On Fri, Mar 11, 2022 at 7:31 AM Cameron Elliott wrote:
>
>
> Ian, thank you very much for the suggestion to use atomics.
> Unfortunately, for a standard SPSC ring
Ian, thank you very much for the suggestion to use atomics.
Unfortunately, for a standard SPSC ring buffer, I don't think it does the
trick.
I am attaching a simple ring buffer program at the end.
If you run 'go run -race main.go' on the example,
a race will occur.
The race that occurs is a w
12 matches
Mail list logo
