DEV Community: Golang

What are goroutines and how are they scheduled?

Matt Boyle — Mon, 04 Apr 2022 07:25:59 +0000

I use goroutines all the time, but I got asked about how they are scheduled recently and I did not know the answer to a sufficient depth. I find writing things down is a great way to ensure I understand them and thought I would turn my notes into a blog in an effort to help others!

If you like this blog post and want to support me to write more whilst learning more about Go, you can check out my site bytesizego.com

What is a goroutine?

Makes sense to start out answering this.

Goroutines are the Go programming language's way of dealing with concurrency (allowing multiple things to happen at the same time). It's worth calling out the difference between concurrency and parallelism as it is an important thing to distinguish. I really like the the take Riteek Srivastav took in his blog post here, so I have copied the paragraph below wholesale. His blog post is an excellent reference on goroutines, so if you want to go a bit deeper than I did here, please check it out:

Here’s an example: I’m writing this article and feel
thirsty, I’ll stop typing and drink water. Then start
typing again. Now, I’m dealing with two jobs (typing and
drinking water) by some time slice, which is said to be
concurrent jobs. Point to be noted here is that these two tasks (writing and drinking) are not being done at the same time.

When things are being done at the same time it’s called
parallelism (Think checking your mobile AND eating chips).
So concurrency is dealing with multiple things at once
(does not need to be done at the same time) with some time schedule and parallelism(doing multiple things at the same time) is a subset of this.

goroutines are cheap to create and very easy to use. Any function in go can be run concurrently by simply appending the go keyword to the function call.

A really naive use might look as follows:

Without goroutines

package main

import (
    "context"
    "time"
)

// cancel is called as functions execute sequentially and take 4 seconds each.
func main() {
    ctx, cancel := context.WithTimeout(context.Background(), time.Second*5)
    defer cancel()
    someLongRunningTaskOne(ctx)
    someLongRunningTaskTwo(ctx)
}

With goroutines:

package main

import (
    "context"
    "time"
)

// The program executes the two functions concurrency.  
// We use a sleep to stop or programming terminating 
// prematurely. More on this below.
func main() {
    ctx, cancel := context.WithTimeout(context.Background(), time.Second*5)
    defer cancel()
    go someLongRunningTaskOne(ctx)
    go someLongRunningTaskTwo(ctx)

    time.Sleep(time.Second * 5)

}

So goroutines are threads?

To people new to Go, the word goroutine and thread get used a little interchangeably. This makes sense if you come from a language such as Java where you can quite literally make new OS threads. Go is different, and a goroutine is not the same as a thread. Threads are much more expensive to create, use more memory and switching between threads takes longer.

Goroutines are an abstraction over threads and a single Operating System thread can run many goroutines.

So How are goroutines scheduled?

Firstly, we always have a main goroutine. This is the programs main "thread" (see, it's hard to avoid this word when discussing them!). When this main goroutine terminates, our program is complete. You always need to keep this in mind as if we do not account for this in our program, you may see some unexpected behaviour. If you look at the example of using goroutines above again, the program will not wait for either of the goroutines to complete before terminating the program. This is why we have to use a time.Sleep() but this means our program has a race condition.

From this main goroutine, we can create as many goroutines as we like, and within those goroutines, we can create goroutines. The below is totally valid go:

package main

import (
    "log"
    "time"
)

func main() {
    go func() {
        go func() {
            go func() {
                go func() {
                    go func() {
                        go func() {
                            go func() {
                                log.Println("maybe I should have thought about this program a little more")
                            }()
                        }()
                    }()
                }()
            }()
        }()
    }()
    time.Sleep(time.Second)
}

Are goroutines called in the order I declared them?

No.

Most Operating Systems have something called a preemptive scheduler. This means that which thread is executed next is determined by the OS itself based on thread priority and other things like waiting to receive data over the network. Since goroutines are abstractions over threads, they all have the same priority and we therefore cannot control the order in which they run.

There has been discussions as far back as 2016 (you can read one such discussion here) about adding the ability to set priority on individual goroutines, but there is some pretty compelling points raised as to why its not a good idea.

How do I ensure my program is as performant as possible?

There is an environment variable (GOMAXPROCS) that you can set which determines how many threads your go program will use simultaneously. You can use this great library from Uber to automatically set the GOMAXPROCS variable to match a Linux container CPU quota. If you are running Go workloads in Kubernetes, you should use this.

If you set GOMAXPROCS to be 3, this means that the program will only execute code on 3 operating system threads at once, even if there are 1000s of goroutines.

It begs the question though, does setting GOMAXPROCS to the biggest value possible mean your program will be faster?

The answer is no, and it actually might make it slower. There are a few reasons for this, but the main reason is to do with context switching.

Swapping between threads is a relatively slow operation, and can take up to 1000ns as oppose to switching between goroutines on the same thread which takes ~200ns. Therefore you may find that for your particular workload, your program is faster with a lower GOMAXPROCS value. Always profile and benchmark your programs and make sure the Go runtime configuration is only changed if absolutely required.

Summary

I hope you found this useful and you came away with a better understanding of what goroutines are how they are scheduled. For more Go tidbits, or to say hey, you find me on Twitter here

What are go workspaces and how do I use them?

Matt Boyle — Mon, 21 Mar 2022 08:46:21 +0000

I previously blogged about generics being added as part of the Go 1.18 release. There was another quality of life improvement that was added with this release called "Go workspaces".

This is what the release notes said about workspaces:

In this blog post, we are going to explore what Go workspaces are and how to use them.

If you like this blog post and want more great Go content, check out bytesizego.com

go mod replace

Have you ever wanted to make a change to one of the Go modules your code depends on? After some googling you might have found yourself doing something similar to the below:

module test1.18

go 1.18

require golang.org/x/sync v0.0.0-20210220032951-036812b2e83c // indirect

replace golang.org/x/sync => ./local/sync

This should be all we need. To test it I copied the code from golang.org/x/sync to ./local/sync. My file tree looks like this:

and then made a small edit to the Go func of errgroup:

and wrote a simple main func:

As expected, when I run my program I get the following output:

2022/03/21 07:58:10 Let's go!
2022/03/21 07:58:10 did a thing

Great, everything works!

Before go 1.18, this was pretty much the only way to make changes to multiple modules at once. You would then need to remember to remove your changes from go.mod before you commit your code.

Introducing Workspaces

With workspaces, this whole process becomes much easier. We can make a go.work file that effectively works the same as the replace directive we used previously. Let's follow the same example again but this time use a workspace file.

My go.mod file is reverted to be as follows:

module test1.18

go 1.18

require golang.org/x/sync v0.0.0-20210220032951-036812b2e83c // indirect

I then make a new file called go.work at the root of my project and added the following:

go 1.18

use ./local/sync

That's truly it! The go tool detects the workspace file automatically and uses it. When I run go run ./workspace/main.go I get the same output as before:

2022/03/21 08:03:43 Let's go!
2022/03/21 08:03:43 did a thing

In the Go 1.18 Beta you were able to run:

 go build -workfile=off ./workspace/main.go

to build the code without using the workfile, but this didn't work for me with the production release. I raised a bug against the go tool here and it looks like it was removed before release which is a shame.

The correct way to do is now to run the following command:

GOWORK=off go run ./workspace/main.go

and with this we get the following output:

2022/03/21 08:27:03 did a thing

This shows it is now building with the original module in our go.mod file.

Best practises and Warnings

Early posts from the community are suggesting that not committing your go.work file is preferable. This makes sense, it is used for local development and after you have made and tested your changes to a module, you should push it, tag it and then reference it in your go.mod file as usual. Therefore, sharing go.work files doesn't make sense.

Consider adding go.work to your .gitignore.

A Warning though, if you do happen to push your go.work file it looks like if you run go build it will use your go.work file by default unless you explicitly turn it off. This could lead to production builds having development code in unintentionally. It therefore might be worth always running production builds with GOWORK=off go build ./... to be on the safe side.

Wrap up

I hope you find this useful. For more go tidbits, you can find me over on twitter here

What are Go Generics & When Should I use Them?

Matt Boyle — Wed, 16 Mar 2022 07:28:48 +0000

Yesterday Go 1.18 was released!

1.18 has been eagerly awaited by the Go Community as it contained the official support of generics in Go as well as a whole host of other features which I hope to cover off in other blog posts in the future. You can read more about the release in the official release notes here.

If you like this blog post and want to support me to write more whilst learning more about Go, you can check out my site bytesizego.com. I have both free and paid courses and writing.

For this blog post, we are going to focus on the following bullet from the notes:

> The syntax for function and type declarations now accepts type parameters.

Type Parameters? What are They?

Type parameters are Go's way to support generics. Generic's allow developers to write "general" code that works for many different data types without having to specify that at the point of code creation. I know that is confusing, so let's look at an example.

Before Go 1.18, lets say we had the following slices we wanted to sum together:

func main() {
    intsToAdd := []int{1, 2, 3, 4}
    floatsToAdd := []float64{1.1, 2.2, 3.3, 4.4}
}

We would need to write the following code:

func sumInts(nums []int) int {
    var res int
    for _, num := range nums {
        res += num
    }
    return res
}

func sumFloats(nums []float64) float64 {
    var res float64
    for _, num := range nums {
        res += num
    }
    return res
}

func main() {
    intsToAdd := []int{1, 2, 3, 4}
    floatsToAdd := []float64{1.1, 2.2, 3.3, 4.4}

    fmt.Println("ints", sumInts(intsToAdd))
    fmt.Println("floats", sumFloats(floatsToAdd))
}

Which outputs:

ints 10
floats 11

This works and there is nothing wrong with it at all. In fact, I imagine some teams will choose to continue to write code like the above due to its clarity.

However, it does lead to a lot of very similar functions as you can see.

With the introduction of generics, we can write this much more succinctly as the following:

func main() {
    intsToAdd := []int{1, 2, 3, 4}
    floatsToAdd := []float64{1.1, 2.2, 3.3, 4.4}

    fmt.Println("ints", sumNumbers(intsToAdd))
    fmt.Println("floats", sumNumbers(floatsToAdd))
}

type Number interface {
    int | int64 | float32 | float64
}

func sumNumbers[n Number](nums []n) n {
    var res n
    for _, num := range nums {
        res += num
    }
    return res
}

This looks pretty confusing to me since I'm not used to it, but I'm hoping over time I get more comfortable reading code like this.

Let's step through it.

Firstly we declare an interface which is going to be our type constraint:

type Number interface {
    int | int64 | float32 | float64
}

Here we are saying anything that is an int, an int64, a float32 or float64 is a Number. Whenever we reference Number, it must be one of these things. This is similar to how we have used Go interfaces in the past.

In the square brackets below we add our type constraint Number and call it n. This means whenever we reference n we are referring to the Number type. The Compiler will do some clever work at compile time to figure out everything else for us.

func sumNumbers[n Number](nums []n)

Now we have told our function that anytime we reference n we are referencing either an int int64, float32 or float64, we can fill in the rest of the code.

Please note that generics does not make the following valid.

// trying to mix ints and floats
NumsToAdd := []Number{1.1,-3, 2.2, 3.3, 4.4}

This is because our Number interface contains a constraint types which means it cannot be used like this (confusing I know).

When should I use Generics?

There is a video from Go team engineer Ian Lance Taylor here which does a great job of walking through use cases. I highly recommend watching it.

In general, it is advised to start with simple functions and only try and write generic functions once you have wrote very similar code 2 or 3 times. In the example above, I would not have considered writing a generic function until I had wrote the sumFloats function and realised how similar it was to the sumInts function.

Hope you found this useful! You can find me on twitter here