-
Notifications
You must be signed in to change notification settings - Fork 230
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Different approach for ring buffer #11
Comments
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 |
go-concurrency-patterns/17-ring-buffer-channel/main.go
Line 28 in 82c2313
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.
The text was updated successfully, but these errors were encountered: