Understanding Real-World Concurrency Bugs in Go [pdf]

The two key takeaways for me are:<p>(1) &quot;Contrary to the common belief that message passing is less error-prone, more blocking bugs in our studied Go applications are caused by wrong message passing than by wrong shared memory protection.&quot;<p>(2) &quot;Shared memory synchronization operations are used more often than message passing, ...&quot;<p>So basically, (1) people have more trouble writing correct multithreaded routines using message passing, and (2) in large production applications people tend to fall back to using shared-memory primitives rather than message-passing anyway.<p>It seems the intention of the Go language designers was to make a language that would be simple and easy for programmers to pick up. Given that most programmers are already accustomed to multithreaded programming using shared memory and that this is conceptually simpler, I think the language designers made a mistake by throwing channels, a relatively new and experimental approach (yes, I know CSP is from 1978, but I&#x27;m talking about widely-adopted industrial languages), into the language. I think it was the single biggest mistake in the design of Go.

Well, yes. Go&#x27;s shared memory model is essentially the same as that of C and C++. You have locks, and you have data objects, and the language has no idea which lock covers what data. That&#x27;s the big thing Rust got right.<p>Go&#x27;s message passing model is somewhat error prone. It lets you pass references. So you can create shared data through the channels. It&#x27;s easy to do this accidentally by passing slices, which are references to the underlying array, across a channel.<p>More generally, Go channels are one-way. Since you often want an answer back, you have to create some two-way mechanism from the raw one-way channels. It seems to be common to do this at the raw channel level, rather than using some &quot;object&quot; like encapsulation. Creating a mechanism which shuts down cleanly is somewhat tricky, too.

confirms some of my suspicions to claims on how sexy and easy go is when it comes to concurrency. if anything it will give you a false a sense of security but god help you in case things go south and you’ve abused these features.

This is pretty good and deserves more attention. Github makes bug studies so much more approachable. Hopefully the study will make people more cautious about Go&#x27;s concurrency model, which is as error prone as shared memory multithreading, if not more.

&quot;Surprisingly, our study shows that it is as easy to make concurrency bugs with message passing as with shared memory, sometimes even more. For example, around 58% of blocking bugs are caused by message passing. In addition to the violation of Go’s channel usage rules (e.g., waiting on a channel that no one sends data to or close), many concurrency bugs are caused by the mixed usage of message passing and other new semantics and new libraries in Go, which can easily be overlooked but hard to detect.&quot;

As much as I don&#x27;t like javascript, there is a whole swathe of concurrency bugs that exists in golang and not in nodejs.

The terminology could use some refinement. Not sure &quot;message passing&quot; is the right phrase to describe Go channels.<p>Most encounters I&#x27;ve had with &quot;message passing&quot;--whether it was AJAX, Win32 PostMessage, or grade school--have been non-blocking. Go channels block.<p>edit: Here&#x27;s a pretty good write-up from 2016 on why channels are an anti-pattern:<p><a href="https:&#x2F;&#x2F;www.jtolio.com&#x2F;2016&#x2F;03&#x2F;go-channels-are-bad-and-you-should-feel-bad&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.jtolio.com&#x2F;2016&#x2F;03&#x2F;go-channels-are-bad-and-you-s...</a>

is there a html version?