> I would ask what is the shared resource that you're synchronizing access to.
The resource is really the internal program state. It's a steering mechanism controlled by various parameters (mode, timings etc) that need be synchronized to avoid races. > I recommend you watch and digest "Rethinking Classical Concurrency Patterns" by Bryan C. Mills: That's on my reading backlog, thank you for the youtube link. > You haven't added channels to your list of patterns Thought about them and discarded. I might make perfect sense to buffer all web input (using channels or whatever) until global lock becomes available. That way the entire main flow could be lock-less. I'll check the talk. Thanks, Andi On Tuesday, March 1, 2022 at 11:00:12 AM UTC+1 Brian Candler wrote: > I would ask what is the shared resource that you're synchronizing access > to. If there's a backend database, usually the database API will have some > sort of thread-safe connection pool, so presumably it's something else. > > > Are there any best practices/ talks/ presentations I could refer to? > > You haven't added channels to your list of patterns. I recommend you > watch and digest "Rethinking Classical Concurrency Patterns" by Bryan C. > Mills: > https://www.youtube.com/watch?v=5zXAHh5tJqQ > I found it very much worth the effort to fully understand the code > examples included. > -- 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/9c5f2c75-5b9f-4b70-9510-0153ff1bfc04n%40googlegroups.com.
