6 ms·
Advanced Go Concurrency Patterns (2013)
- stesch 12y ago> This talk was presented at Google I/O in May 2013.
- dang 12y ago...and discussed here: https://news.ycombinator.com/item?id=5760532 https://news.ycombinator.com/item?id=5760532
- ashearer 12y agoExcellent 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.
- mseepgood 12y agoVideo here: https://www.youtube.com/watch?v=QDDwwePbDtw https://www.youtube.com/watch?v=QDDwwePbDtw
- nnain 12y agoI 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.
- bsaul 12y agoIs there a performance comparison anywhere between creating a big API of channel, each for every different task that you may want to achieve ( let's say add/search/remove from a global slice), versus simply performing mutex to protect the state mutation ? 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.
- slimsag 12y ago(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.html) 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.
- zzzcpan 12y agoI 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.
- thirsteh 12y agoRWMutex (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.
- namelezz 12y agoDoes anyone know what pros and cons this pattern have compared to callbacks? I note most UIs developments still use callback approach.