Different approach for ring buffer
ansoni-san opened this issue · comments
This is a bug surely? Another routine could write between these two calls, and then this write would block.
A safer approach would be to drop the current write AND one from the ring buffer. This would ensure that no code ever blocks, but you are still guaranteed new data (which IMO is a big use-case for ring buffers).
This would ensure no back-pressure. It would make starvation technically possible very rarely by some complex timing and workload patterns if you have too many writers for the size of the ring buffer, but this is trivial to avoid by sizing the ring buffer appropriately.
So as long as your ring buffer isn't too small, I think it would behave more like what people would expect.
Agreed, in its current form the code is prone to deadlocking. Proof: https://github.com/lotusirous/go-concurrency-patterns/compare/main...attila-kun:deadlock?expand=1#diff-feadaed927370e3ae128f41c317b1b3f57d3b0b2900612ce96314c4a9fcb9bd8R30
It required the introduction of an artificial delay before r.outCh <- v and a concurrent consumer of outCh but if you run the above, the result is a deadlock (might need to run multiple times, it doesn't always happen).