Hacker News new | past | comments | ask | show | jobs | submit login
Advanced Go Concurrency Patterns (2013) (golang.org)
90 points by _zhqs on Jan 3, 2015 | hide | past | favorite | 12 comments



Is 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.


(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.


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.


s/anywhere/everywhere/ ?


Sorry, yes.


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.


> This talk was presented at Google I/O in May 2013.





Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: