Advanced Go Concurrency Patterns (2013)(talks.golang.org)
talks.golang.org
Advanced Go Concurrency Patterns (2013)
http://talks.golang.org/2013/advconc.slide#1
12 comments
(I don't know about performance differences)
> I've seen a golang informal chat where one of the golang team member advertized using mutex instead of having a huge select, but i wonder if anyone has real experience of the two here.
My "real experience" here, and the opinion of other Go users I've talked with is that you should use the right tool for the right job.
Channels are awesome and open room for a lot of interesting opportunities. Something interesting I've done is using channels of functions (closures) to have OpenGL code sent over a channel to run on the main thread (see [here](http://slimsag.blogspot.com/2014/11/go-solves-busy-waiting.h...). That is a one-off/odd example by many, but it shows how versatile they really are.
Sometimes using a mutex makes the code cleaner, though. I wouldn't use a channel to just protect a single variable shared by multiple goroutines, for instance. A mutex may make more sense in a lot of situations, lo and behold, if it does then just use a mutex then.
> I've seen a golang informal chat where one of the golang team member advertized using mutex instead of having a huge select, but i wonder if anyone has real experience of the two here.
My "real experience" here, and the opinion of other Go users I've talked with is that you should use the right tool for the right job.
Channels are awesome and open room for a lot of interesting opportunities. Something interesting I've done is using channels of functions (closures) to have OpenGL code sent over a channel to run on the main thread (see [here](http://slimsag.blogspot.com/2014/11/go-solves-busy-waiting.h...). That is a one-off/odd example by many, but it shows how versatile they really are.
Sometimes using a mutex makes the code cleaner, though. I wouldn't use a channel to just protect a single variable shared by multiple goroutines, for instance. A mutex may make more sense in a lot of situations, lo and behold, if it does then just use a mutex then.
RWMutex (or Mutex if every op is a write op) is faster since it's just a couple counters and atomic AddInt. Channels are more intuitive for some tasks, and less for others. Don't try to use channels anywhere, especially when you're just synchronizing access to something.
Source: Have written and benchmarked many, many Go programs.
Source: Have written and benchmarked many, many Go programs.
I think waiting on a channel takes something like 1000 cycles or at least on that order. And large buffer halves that number. But you know, microbenchmarks are not very meaningful per se.
Does anyone know what pros and cons this pattern have compared to callbacks? I note most UIs developments still use callback approach.
I like these slides that are hosted on golang.org -- navigating them on the browser gets a bit restrictive though. I figured if you "Print/Save to pdf" from your web browser, you can get a nice pdf copy.
Excellent talk, even if you've seen it before.
Note that the slide viewer scrolls horizontally across the first few slides, but you need to use the keyboard (spacebar) to advance further.
Note that the slide viewer scrolls horizontally across the first few slides, but you need to use the keyboard (spacebar) to advance further.
> This talk was presented at Google I/O in May 2013.
...and discussed here: https://news.ycombinator.com/item?id=5760532
I've seen a golang informal chat where one of the golang team member advertized using mutex instead of having a huge select, but i wonder if anyone has real experience of the two here.