For what it's worth, I would argue that the 1-buffered channel pattern in Go *is* “basic concurrent programming”. 1-buffered channels are used as basic building blocks throughout the standard library — consider time.Ticker or signal.Notify — and for good reason. A 1-buffered channel is a very simple and versatile concurrent container.
For a good analogy, you can think of it like a physical transaction drawer <https://www.quikserv.com/drawers/transaction-drawers/> or secure package receiver <https://www.quikserv.com/transaction-windows/secure-package-receivers/> or lock box. The container may have a value in it (say, a bank deposit bag), but in order to access that value one party (perhaps the teller) needs to open the container and remove its contents, and only one party may do so at a time. That party may update the contents (perhaps removing the deposit from the bag), and then put the updated value (the empty deposit bag) back in the container. The nature of the container ensures that only one party can manipulate the item at a time. On Tuesday, April 13, 2021 at 9:00:33 AM UTC-4 leven...@gmail.com wrote: > Jesper, a single channel works if I provision it with big enough capacity > (1000), but this feels like an antipattern which can break. Still, this is > probably the most practical option. > > Brian, thanks for sharing, yes this pattern solves my problem much simpler > than I have. Although it doesn't feel right that achieving something that > feels like basic concurrent programming turns into Koan solving. > > On Tue, 13 Apr 2021 at 14:43, Brian Candler <b.ca...@pobox.com> wrote: > >> Bryan Mill's presentation on go concurrency patterns is well worth >> watching all the way through: >> https://www.youtube.com/watch?v=5zXAHh5tJqQ >> >> There are lots of code snippets which are directly relevant to what >> you're trying to do, e.g. from 20:48 is a queue with Get, and 21:59 a queue >> with GetMany. He starts with the traditional semaphore approach and then >> shows a much cleaner and simpler way of doing it. >> >> The biggest revelation I got was: instead of having a data structure >> protected by a mutex, you can stuff a data structure into a one-element >> buffered channel. When you need to use it: pop it out, modify it, push it >> back in. Very easy to reason about. >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "golang-nuts" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/golang-nuts/bNF_KXUiKHs/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> golang-nuts...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/7b198a7b-daaf-435b-930f-bb318dd838e3n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/7b198a7b-daaf-435b-930f-bb318dd838e3n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7068c5cb-e40b-41ee-98e1-85f2a5ca1e16n%40googlegroups.com.
