Mutexes are good for a some low level tasks, and when you must have a shared data structure with no clear owner. When in doubt, and when designing your app, prefer communication over sharing, i.e. channels.
On Fri, Aug 18, 2017, 16:03 John Souvestre <j...@souvestre.com> wrote: > Interesting. So you think it is a general safety advisory (which would > apply to any language) to use synchronization (ex: mutex or channel) and > not a more focused push to use channels? Hmmm... I didn't understand it > that way. I thought that "communicate" was a reference to the "C" in CSP. > It never crossed my mind that it would mean "use synchronization". > > The context of the Go FAQ section which includes the proverb discourages > mutexes (with no mention of when they should or should not be used). The > two links it provides bolster this and only provide examples using channels. > > The wiki article MutexOrChannel starts off with the proverb then > immediately follows with "That said, Go does provide traditional locking > mechanisms in the sync package." Why the need to say this if the moto was > meant to include the sync methods, too? > > Everything I recall reading or listening to which references the proverb > seems to continue in this theme to avoid locking. Here's a rather explicit > one from > https://dave.cheney.net/2016/11/13/do-not-fear-first-class-functions: " > Don’t communicate by sharing memory, share memory by communicating. Our > first proverb–don’t mediate access to shared memory with locks and mutexes, > instead share that memory by communicating." > > Also, in Rob Pike's talk "Go Proverbs" at Gopherfest on 11/18/2015 he > talks about this proverb. He defines "sharing memory by communicating" as > "passing on a channel the address of a data structure or an object ...". > > So I don't think that I'm alone in thinking that the focus of the proverb > is to use channels to share memory, rather than any other way. And I find > this somewhat wrong and certainly confusing. Am I really alone in this? > > John > > John Souvestre - New Orleans LA > > > -----Original Message----- > From: Ian Lance Taylor [mailto:i...@golang.org] > Sent: 2017 August 18, Fri 15:14 > To: John Souvestre > Cc: golang-nuts > Subject: Re: [go-nuts] Go channels overused and hyped? > > On Fri, Aug 18, 2017 at 12:02 PM, John Souvestre <j...@souvestre.com> > wrote: > > > > I think that both of the suggestions below are great. But I�m left > > wondering about the Go mantra > > > > > > > > Do not communicate by sharing memory. Instead, share memory by > > communicating. > > > > > > > > What does it say? It starts off with communicating as the goal, but > doesn�t > > tell you how to do it. Then sharing memory is the goal and the solution > it > > provides (communicating) is only right some of the time. > > > > > > > > Am I missing something? Should this be replaced? > > As I see it, the point of the proverb is to focus on having goroutines > use explicit communication mechanisms, such as channels and mutexes, > to hand control of an area of memory over to another goroutine. An > example of communicating by sharing memory would having one goroutine > poll a memory location that is then changed by a different goroutine. > As a general guideline, prefer explicit communication mechanisms. > > Ian > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
