View profile

Concurrency in Go #1 - Software Shots

Concurrency in Go #1 - Software Shots
By Karn • Issue #12 • View online
Hi there 👋 . First software shot as a full-time software engineer. 😛
So thought about starting a new series, where we both learn at the same time. The plan is to get you up to speed with goroutines, channels, closures, etc., and slowly move on to more advanced concepts.

One of the most basic units of organization in a Go program. Every go program has at least one goroutine: the main goroutine, which is automatically created and started when the process begins.
sample goroutine
sample goroutine
Go hosts goroutines in implementation of M:N scheduler, which means it maps M green(virtual) threads to N OS threads. Goroutines are then scheduled onto the green threads. (More on this in future shots)
Here, the hello() function will run on its own goroutine, while the rest of the program continues executing. However, there’s one problem here, it’s undetermined whether hello will run before our program exits or not. So we need some sort of join point.
Have a look at the following, we used a WaitGroup from the sync package to add a join point to the main and hello goroutine.
The defer statements run at the end of the function, and so we mark wg as Done(), once we print hello.
Closures close around the lexical scope they are created in, thereby capturing variables. Let’s try a tricky program and check out the output:
range over an array, print in goroutine
range over an array, print in goroutine
What do you think the output will be?
The answer is trickier than most of us expect and is one of the few surprising things in Go. The output on my machine is:
As our loop iterates, the number is being assigned to the next value in the array. And since the goroutines can be scheduled at any point in time in the future, it is undetermined what values will be printed from within the goroutine.
On my machine, there is a high probability that the loop exited before any goroutines even began and the variable number fell out of scope.
But then a new question arises, ie. Can the goroutines reference something that has potentially been garbage collected?
Cool fact about how Go manages memory: The Go runtime is observant enough to know that a reference to number variable is still being held, and therefore will transfer the memory to the heap so that goroutines can continue to access it.
So the loop exited before the goroutine could run, and the last value which was held in the variable got printed three times.
The solution to this: (Closure)
goroutines run in same address space as each other
goroutines run in same address space as each other
That’s about it for this shot. We’ll have more practical fun in the upcoming shots.
Have a good week. Ciao! 👋
Did you enjoy this issue?
By Karn

I build and create things. As of now, I work as a Software Engineer at SendX/SendPost.

If you don't want these updates anymore, please unsubscribe here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue
Gyan Karn, Delhi, India - 110039